Требования, предъявляемые к базе данных. Этапы жизненного цикла базы данных. Требования к бд Требования предъявляемые к бд

Изучением этого вопроса долгое время занимались различные группы людей в учреждениях, использующих компьютеры, в правитель-ственных комиссиях, на вычислительных центрах коллективного пользования. Комитет CODASYL опубликовал отчеты на эту тему (CODASYL--организация, разработавшая язык КОБОЛ). Организации пользователей IBM SHARE и GUIDE в своем отчете сформулировали требования к системе управления базами дан-ных. Организация ACiM (Association for Computing Machi-nery) также занималась изучением этого вопроса.

Ниже перечислены основные требования к организации базы данных.

Установление многосторонних связей

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

Производительность

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

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

Минимальные затраты

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

1. Требования к БД

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

Основные требования к организации БД:

1. Установление многосторонних связей 2. Производительность

3. Мин. Затраты 4. Мин. Избыточность (мин. Использование памяти)

5. Возможность поиска 6. Целостность (восстановление данных)

7. Безопасность и секретность (без – защита от доступа третьих лиц, секр – возможность руководит без.)

[Как обеспечить безопасность:

а. Данные должны быть восстановимы б. Возможность контроля данных

в. Система недоступна для вмешательства в нее

г. Процедура идентификации

д. Данные защищены от хищения, уничтожения, изменения

е. Контроль действий пользователя с точки зрения допустимости]

8. Связь с прошлым. Совместимость версий

9. Связь с будущим. Данные отделены от их представления

10. Настройка БД 11. Перемещение данных 12. Простота

2. Основные компоненты СУБД

Абстракция" href="/text/category/abstraktciya/" rel="bookmark">абстракция , которая, будучи приложена к конкретным данным, позволяет пользователям и разработчикам трактовать это как информацию, то есть сведения, содержащие не только данные, но и связь между ними.

Ограничение целостности – не противореч. данных задан. логич. огранич.

Огранич. зад-тся не только для атриб-тов, но и для типов объ-тов и связей.

Виды связи : 1:1 1:M M:1 M:M

Модель данных , поддерживаемая БД на логическом уровне определяется 3 компонентами:

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

2. Множество допустимых операций над данными

3. Ограничения для контроля целостности.

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

0 " style="border-collapse:collapse;border:none">

Сотрудник

Сущность

Табельный номер

Ключевой атрибут

Атрибуты

Дата рождения

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

https://pandia.ru/text/78/193/images/image004_68.gif" width="17" height="17">Связь может быть

Между двумя сущ. может быть много связй с разными смысл. нагрузками.

Можно использовать принцип категоризации сущности, то есть наследовать сущности друг от друга (как в ООП). Сущность-родитель, от которой строятся подтипы, называется супертипом.

Для построения модели ER проводится системный анализ.

Для библиотеки это будет книги-экземпляры-читатели.

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

В основе лежит математическая теория отношений.

Массив данных, представленный реляционным набором структур, образует реляционную БД, и схема РБД будет представлена набором схем-отношений. R1(A11,A12,A13,..A1k) R2(A21,A22,A23,..A2k) R3(A31,A32,A33,..A3k), где R-отношения, A-атрибуты. Пусть A, B атрибуты отношения R.

Говорят , что B функционально зависит от A , если в каждый момент времени каждому A соотв. не более одного значения B.

Если имеется мн-во атрибутов A1-An отношения R, а также множество функц. Завис. XàY, где X и Y подмножества A1-An, Тогда из функц. Завис., входящих в мно-во F могут быть выведены другие функц. Завис., присущие R. F + - замыкание множества ф-х зависимостей, т. е. полное множество зависимостей, которые могут быть получены из F. Св-ва:

1. Рефлексивность: XÍU, YÍU, YÍX, то XàY

2. пополнение: XÍU, YÍU, ZÍU, XàY, то XÈZàYÈZ

3. транзитивность: XÍU, YÍU, ZÍU, XàY, YàZ, то XàZ

4. расширения: XÍU, YÍU, XàY, то "ZÍU XÈZàY

5. продолжения XÍU, YÍU, WÍU, ZÍU, XàY, то "WÍZ, XÈZàYÈW

6. псевдотранзит. XÍU, YÍU, ZÍU, WÍU, XàY, YÈWàZ, то XÈWàZ

7. аддитивность. X, Y,ZÍU XàY, XàZ, то XàYÈZ

Домен – совокупность однотипных значений данных

Степень отношения – число атрибутов, входящих в отношение.

Мощность – число кортежей отношения.

Интенсионал A(R1..Rn) – интенсионал

Экстенсионал – некоторое заполнение кортежей отношений.

Ключ K отношения R - комбинация атрибутов, обладающих следующими свойствами:
1. в каждом кортеже отношения R величина k единственным образом определяет этот кортеж

2. не существует атрибута в ключе k, который может быть удален без нарушения св-ва 1.

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

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

Элементы реляционной модели

Форма представления

Отношение

Схема отношения

Заголовок таблицы

Строка таблицы

Сущность

Свойства объекта

Заголовок столбца

Множество допустимых значений атрибута

Значение атрибута

Значение поля записи

Первичный ключ

Один или несколько атрибутов

Тип значений элементов таблицы

9. 6 видов простых запросов :

пусть E1-En - набор объектов. A1-An – множество атрибутов. K11-Knm – домены атрибутов

Тип запроса

Значение атрибута

Какой объект имеет заданное значение

Какой атрибут имеет значение

Все атрибуты объекта

Данный Атрибут для всех объектов

Все, что равно V

10. Алгоритм преобразования ER в РМД:

1. Каждой сущности ER соответствует отношение РМД.

2. Каждый атрибут сущности становится атрибутом соответствующего отношения.

3. Первичный ключ сущности становится первичным ключом соответствующего отношения.

4. В каждое отношение соответствующее подчиненной сущности добавляется набор атрибутов основной сущности, являющийся первичным ключом основной сущности

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

6. Для отражения категоризации сущности при переходе в РМД возможны несколько вариантов представления. Возможно создать только одно отношение для всех подтипов супертипа. Достоинство – создается всего одно отношение. Недостаток – избыточность. Второй подход – свое отношение для каждого подтипа.

11. НФ1, НФ2, Аномалия

1НФ : каждый атрибут отношений является простым атомарным атрибутом, т. е. отсутствуют составные.

2НФ : отношение нормировано, то есть каждый атрибут полностью зависит то первичного ключа.

Аномалия – такая ситуация в таблице БД, которая приводит к противоречиям в БД, либо существенно усложняет обработку данных.

Разновидности аномалий:

1. избыточность – одинаковые элементы информации повторяются многократно в нескольких кортежах.

2. аномалии изменения – один и тот же фрагмент данных изменяется в одном кортеже, но остается нетронутым в другом.

3. аномалия удаления – если множество значений становится пустым это может косвенным образом привести к потере другой информации

Один из способов устранения аномалии – декомпозиция отношения. Декомпозиция отношения R предполагает разбиение множества атрибутов R c целью построения схем двух новых отношений с последующим занесением в эти отношения определенных в отношении R кортежей. Например таблицу “поставщик, товар, цена” надо разбить на две. В противном случае:

Аномалия включения: пока поставщик не начнет поставлять товар, мы не сможем узнать информацию о товаре.

Аномалия удаления: если поставка товара прекращается, теряется вся информация о товаре.

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

12. НФ3

3НФ : каждый непервичный атрибут в отношении R не содержит транзитивных зависимостей от первичного ключа.

Например : хранение (фирма, склад, объем)

Каждая фирма – только с одного склада. Фирмаàсклад, складàобъем

Аномалия включения: Если никто не получает со склада товар, мы не знаем его объем

Аномалия удаления: если последняя фирма перестает получать товар со склада, инфа о складе теряется

Аномалия обновления: если объем склада меняется, нужно менять все объемы для всех фирм

Усиленная 3НФ: в отношении отсутствует зависимость первичных атрибутов от непервичных.

Или Необходимо, чтобы все домены функц. зависимостей были возможными ключами

Например проект(Деталь, проект, поставщик)

В проекте несколько деталей. Каждая деталь – только одним поставщиком. Каждый поставщик обслуж. только один проект.

Деталь, ПроектàПоставщик

ПоставщикàПроект

Аномалия включения: Факт поставки деталей не может быть занесен, пока детали не начнут использовать

Аномалия удаления: Если поставщик ничего не поставляет, его придется убить

Аномалия обновления: Если меняется поставщик какого либо типа деталей, придется менять асе кортежи

13. Пример НФ1,НФ2,НФ3

Отошение преподаватель-предмет

№ препода

Название предмета

Кол-во часов

Фамилия препод.

Должность

Отношение с составным ключом номер препода, название предмета.

Функциональные зависимости:

Должностьàоклад, номерàфамилия, кафедраàтелефон, должностьàоклад

Имеется транзитивная зависимость номерàкафедраàтелефон. Значит отошение находится в 1НФ. Имеет место неполная функциональная зависимость фамилия, должность, оклад от части ключа №препода. Эта неполная зависимость приводит к следующим аномалиям:

1. имеет место дублирование данных о преподавателях.

2. проблема избыточности данных. Изменение оклада приводит к изменению кортежа

3. Возникает проблема с преподавателем, который не ведет предметы.

4. Если препод. уходит, приходится удалять предмет.

Чтобы перейти в 2НФ разобьем составной ключ на части, и разделим по зависимости:

Имеются транзитивные зависимости номерàкафедраàтелефон, номерàдолжн.àоклад

Это приводит к аномалиям:

1. дублирование информации о телефоне

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

3. нельзя включать данные о новой кафедре, если там нет преподов.

Переходим в 3НФ

14. Переход к 4НФ

Многозначная зависимость существует если при заданных значениях атрибута X существует множество, состоящее из 0 или более взаимосвязанных значений атрибута Y, причем множество значений атрибута Y связано со значением атрибута отношением U-X-Y, где U – все множество атрибутов отношений.

Обозначение многозначной зависимости X->>Y.

Аксиомы многозначной зависимости

1. дополнение X>Y, то X->>U-X-Y

2. пополнение Если X>Y, то WuX->>VuY

3. транзитивность Если X>Y, X->>Z, то X->>Z-Y

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

1. объединение Если X>Z, X->>Y, то X->>YuZ

2. псевдотранзитивность Если X>Y, WuY->>Z, то WuX->>Z-WuY

3. смешанное правило транзитивности Если X>Y, XuYàZ, то XàZ-Y

4. правило декомпозиции X>X, X->>Z, то X->>X^Z, X->>Y-Z, X->>Z-Y

Рассмотрим зависимость (№, курс, дети, должность)

Между преподавателем и курсом связь M:M

Между преподавателем и детьми 1:M

Многозначные зависимости №->>курс, №->>дети

Схема отношения находится в 4НФ, если всякий раз, когда существует многозначная зависимость X->>Y, где Y непусто, и не является подмножеством X, и XvY состоит не из всех атрибутов R, X содержит к-н ключ отношения R, атрибуты, между которыми существует многозначная зависимость, выделяют в отдельные отношения

R1(№,курс) R2(№,дети) R3(№,должность)

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

Обратимость предполагает:

1. Отсутствие потери кортежей 2. Не появляются ранее отсутствующие кортежи 3. Сохраняются функциональные зависимости

15. Переход в 5НФ

Отношение в 5НФ <=> любая зависимость по соединению V определяется возмож. ключами R иначе каждая проекция R содержит не менее одного возможного ключа и по крайней мере один непервичный атрибут

Процесс нормализации отношений последовательно устраняет следующие типы зависимостей:

1. частичные зависимости неключевых атрибутов от ключа

2. транзитивные зависимости неключевых атрибутов от ключа

3. зависимости ключей от неключевых атрибутов

4. многозначные зависимости

16. Соединение без потерь, сохраняющих зависимость

Из всех возможных разложений схемы должны использоваться только те, которые обладают свойством соединений без потерь . Пусть в схеме R имеется множество функциональных зависимостей. Говорят, что схема R разложима без потерь на отношения R1,R2,Rk, с сохранением функциональной зависимости, если для каждого кортежа r из R может быть r восстановлен соединением его проекций.

Условия отсутствия потерь при соединении:

Если R1 и R2 являются разложением R, с сокращением функциональных зависимостей – это разложение обеспечивает соединение без потерь с сохранением функциональной зависимости <=> если R1^R2àR1-R2 либо R1^R2àR2-R1 при многозначной зависимости R1^R2->>R1-R2, либо R1^R2->>R2-R1

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

Пример:

Служащие(№,отдел, город)

1 разложение E1(№, отдел) E2(№, город)

2 разложение E3(№, отдел) E4(отдел, город)

1. E1^E2=№ E1-E2=отдел E2-E1=город. №àотдел, №àгород условие удовлетворяет, разложение без потерь.

2. E3^E4=отдел E3-E4=№ E4-E3=город. отделà№, отделàгород эти зависимости в исходном разложении не существуют, а исходные функциональные зависимости утеряны, значит это разложение с потерями.

Для разложений более чем из двух отношений можно использовать метод Табло

17. Метод Табло

Дано множество функциональных зависимостей, схема отношения полученная в результате разложения. Процедура состоит в построении таблицы, строками которой являются разложенные отношения, а столбцами – список атрибутов этих отношений без повторений. Таблица заполняется символом aj если элементы строки i в столбце j соответствуют атрибуту Aj отношения Ri в противном случае ставится bij. После построения таблицы следует просмотр всех функциональных зависимостей XàY если для атрибутов из X найдутся строки, где в соответствующих местах стоят aj, то элементы bij этих строк соответствующие столбцам атрибутов из Y заменяется на aj. Если в результате появляется строка таблицы, полностью заполненная aj, то это соединение без потерь.

Пример : R(A, B,C, D) Ф. З. AàC, BàC, CàD.

Разложили: R1(A, B) R2(B, D) R3(A, B,C) R4(B, C,D)

Есть строки со всеми a, разложение без потерь.

18. Реляционная алгебра.

Две группы операций: Традиционные: объединение, пересечение, разность, декартово произведение Специализированные: проекция, ограничение, соединение, деление.

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

Пересечение Получают однотипные кортежи для, общие для R1 и R2

Разность Получаем кортежи, входящие в R1, но не входящие в R2

Декартово произведение Объединяем столбцы как в обычном ДП

Проекция Операция заключается в том, что из отношения R выбираются столбцы, и компонуются в указанном порядке

Ограничение Включают в выходное отношение множество строк, удовлетворяющее заданному ограничению. Пример: R

Соединение Обратная операции проекции. Берутся два отношения, и соединяются, используя указанный атрибут (JOIN): Пример: R1∞R2

Деление R1÷R2=П1,2..n-m(R1)- П1,2..n-m(П1,2..n-m(R1)xR2-R1)

Где R1-n местное отн-ие, R2-mместное отношение n>m. Не дошли руки

19. Реляционное исчисление с переменными кортежами

Формула реляционного исчисления помимо арифметических операций включает дополнительные логические операции (A и E). Используются также операции И, ИЛИ, НЕ.

Формулы реляционного исчисления строятся из атомов и совокупности арифметических и логических операторов, выражение реляционного исчисления с переменными кортежами может иметь вид:

{r|Ψ(r)},где r-кортеж, Ψ(r) – некоторая формула исчисления.

Пример; {r|R1(r)^R2(r)} – необходимо получить множество всех кортежей, таких, что они принадлежат отношениям R1 и R2.

Атомы формул бывают трех типов:

1. R(t), где R – имя отношения, t – кортеж в отношении

2. s[i]θu[j], где s и u – переменные кортежи, θ – арифметический оператор. i, j – номера или имена интересующих столбцов. S[i]- i-й компонент кортежа переменной S u[j]-… 3. s[i]θa, или aθs[i], где a=const.

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

Выражение в РИ является безопасным, если:

1. Из истинности Ψ(t) следует, что каждый компонент кортежа t принадлежит D(Ψ).

2. Для любой подформулы вида (Eu)(Ψ1(u)) входящей в состав Ψ, из истинности Ψ1(u) следует, что u принадлежит D(Ψ1).

3. Для любой подформулы вида (Au)(Ψ1(u)), входящей в состав Ψ, из истинности Ψ1(u) следует, что u не принадлежит D(Ψ1).

Множество D(Ψ) определяется как функция фактических отношений , которая указывается в Ψ(t) констант, присутствующих в формуле Ψ(t) и элементов кортежей тех отношений, которые указывают в θ(t)

D(Ψ)={a1Ψ}U{a2Ψ}U…U{anΨ}UП1(R1)U…UПk(Rn), где aiΨ – const, встреч. В формуле Ψ(t),

Пi(Rj) – проекции кортежей фактических отношений R1-Rn встретившихся в формуле Ψ(t), то есть, в данном случае, компоненты кортежей.

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

20. Реляционное исчисление с переменными на доменах.

Строится так же, как и исчисление на кортежах (с использованием тех же самых операторов).

1. Чего то там Этот атом указывает, что значение тех xi, которые являются переменными д. б. выбраны так, чтобы (x1..xk) было кортежем отношения R.

2. xθy, где x, y-const, или переменные на некотором домене. θ – арифметический оператор сравнения, смысл атома заключается в том, что x и y представляют собой значения, при которых истинно xθy. Формулы в РИ с переменными на доменах также используют A, E, И, ИЛИ, НЕ. Аналогично используются понятия свободной и связанной переменной .

Формула РИ с переменными на домене имеет вид: {x1..xk|Ψ(x1..xk)}, где Ψ – формула, обладающая тем свойством, что только ее свободные переменные на доменах являются различн. Перемен. X1..Xk.

Выражение РИ c переменными на доменах является безопасным , если

1. Из истинности Ψ(x1..xk) следует, что xi принадлежит D(Ψ).

2. Если существует и (Eu)(Ψ1(u)) является подформулой Ψ, то из истинности Ψ1(u) следует, что u принадлежит D(Ψ1)

3. Если для любого u (Au)(Ψ1(u)) является подформулой Ψ1(u) следует, что u не принадлежит D(Ψ1).

Каждому выражению с переменными на доменах существует эквив-е ему выражение реляционного исчисления с переменными на кортежах.

Выражение строится следующим образом:

1. Если t является кортежем арности k, то вводится k новых переменных на доменах t1..tk 2. Атомы R(t) заменяются атомами R(t1..tk) 3. Каждое свободное вхождение t[i] заменяется на ti 4. Для каждого кванта (Eu) и (Au) вводится m новых переменных на доменах u1..um, где u-арность кортежа. В области действия выполняются следующие замены:

RmàR(U1..Um) U[i]àUi EUàEU1..EUm AUàAU1..AUm

Выполняется построение выражения {t1..tk|Ψ`(t1..tk)}, где Ψ’, это Ψ, в которой выполнены соответствующие замены.

21. Сравнение алгебраических языков и языков исчисления.

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

Выражение реал. Алгебры наоборот, специфицирует конкретный порядок выполнения операций. Пример: ISBL (Information System Base Language).

Пример языка на доменах: QBE Пример языка на кортежах: SQL

SQL : Не процедурный язык. Как правило встроен в среду некоторого языка программирования. Ориентирован на доступ к данным, и не обладает свойствами языка разработки.

Методы использования встроенного SQL :

1. статический: функции языка SQL включены в. exe после компиляции

2. динамический: динамическое построение SQL вызовов и интерпретация. Используется, когда заранее неизвестна форма запроса.

DDL(Description)Create table, drop table, alter table, create view, drop view, alter view, create index, drop index.

DML(Manipulation)delete(удалить строки), insert (вставить), update(обнов.).

DQL(Query) Select

DCL(Data control language) Используется для управления доступом.

Alter password, grant, rewoke.

УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ Commit, rollback

22. Транзакции

Виды транзакций:

1. Плоские (классические, ACID). Свойства:

атомарности – транзакция должна быть выполнена целиком, или не выполнена вообще

согласованности – транзакция не нарушает взаимной согласов-ти данных

изолированности – конкурирующие на доступ к БД транзакции фактически обрабатываются последовательно.

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

Фиксация транзакции – запись измененных данных на диск. После этого они будут видны другим транзакциям.

Откат транзакции - отмена.

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

Принципы восстановления:

1. результаты зафиксированных транзакций должны быть в БД.

2. результаты незафиксированных транзакций должны отсутствовать.

Возможны следующие ситуации, при которых требуется восстановление состояния БД:

1. Индивидуальный откат транзакции (стандартный, аварийное завершение работы, в результате блокировки).

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

3. Восстановление после поломки основного носителя БД (жесткий сбой). Основа восстановления – архивная копия и журнал БД.

Основа восстановления – избыточное хранение данных. Избыточные данные хранятся в журнале, и содержат информацию об изменениях в БД. Возможны 2 варианта:

1. Отдельный (локальный) журнал для каждой транзакции – для откатов.

2. Глобальный журнал для восстановления после сбоев.

23. Параллельное выполнение транзакций

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

1. В ходе выполнения транзакции пользователь видит только согласованные данные.

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

1. Совместный (shared). Нежесткая блокировка. Выполняется при чтении объекта.

2. Жесткая (exclusive). Монопольный захват объекта для операции записи.

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

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

Самая простая. Появилась первой. Основные информационные единицы база данных , поле, сегмент.

Поле – мин. и независимая единица данных, доступная пользователю с помощью СУБД.

Сегмент (DBTS) - называется записью.

Тип сегмента – поименованная совокупность типов данных.

Экземпляр сегмента образуется из конкретных значений полей.

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

Сегменты объединяются в древовидный орграф.

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

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

1. Существует 1 корневой сегмент

2. Каждый лог. Исх. Элемент м. б. связан с любым числом подчненных.

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

Сегмент является экземпляром типа сегмента. Между экземплярами сегмента также существует иерархическая связь.

Близнецы – потомки одного типа с одним предком.

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

Для организации физического размещения используются следующие группы методов:

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

2. Нелинейным списком

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

Механизмы поддержания целостности между отдельными деревьями отсутствуют.

(+) 1. Эффективное использование памяти ЭВМ

2. Высокая скорость операций над данными

3. Удобно для работы с иерархически упорядоченными данными

5. Классы могут содержать методы.

6. Классы могут содержать генераторы методов.

7. Многие общие характеристики поведения объектов могут автоматически управляться Cache. Также поведение объектов может определяться пользователем.

Виды классов :

классы типов данных

Классы объектов

Незарегистр. Классы

Зарегистр. Классы

Встраиваемые классы

Хранимые классы

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

Классы объектов: определяют структуру и поведение объектов данного типа. Объекты называют экземплярами соответствующего класса. Каждый класс обладает именем, свойствами и методами.

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

Ограничения:

1. Система не выделяет память для значений свойств объектов.

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

4. Переменные, ссылающиеся на незарегистрированные объекты должны декларироваться с указанием соответствующего класса.

Зарегистрированные классы имеют полный набор методов. Автоматически наследуют методы управления объектов от системного класса. Экземпляры существуют временно в памяти процесса. Их называют временными объектами. Созданием новых объектов, зарегистрированных классов и управлением их размещения в памяти занимается Cache. Наследуются от Library Registered Object. Допускают полиморфизм.

Встраиваемые классы могут храниться не только временно в памяти, но и продолжительное время в БД. Эти классы наследуют свое поведение от класса Library Serial Object. Главное в их поведении – то, что экземпляры в памяти существуют как независимые объекты и могут быть сохранены в БД лишь будучи встроенными в другие объекты.

Хранимые классы обеспечивают длительное хранение экземпляра в БД. Наследуются от Library Persistent. Экземпляры обладают однозначными объектными идентификаторами и могут независимо храниться в Cache. Когда хранимый объект используется как свойство класса говорят о ссылке на хранимые объекты.

Элементы класса :

1. Название

2. Ключевые слова

3. Свойства, то есть элементы данных, хранящихся в классе. Могут быть константами, встроенными объектами и ссылками на хранимые объекты. Классы типов данных не содержат свойств. При доступе к свойствам возможно изменение формата и другое преобразование. Объекты, на которые делаются ссылки автоматически загружаются в память. Свойства могут быть public и private.

4. Методы, то есть код, реализующий те или иные функциональные возможности.

5. Параметры класса, значения, осуществляющие формирование класса во время компиляции.

Типы данных реализуются классами.

Классы могут

1. Выполнять преобразование данных между форматами, хранимыми в БД, памяти, памяти и отображаемыми.

2. Отвечают за проверку значений

3. Обеспечивают взаимодействие с SQL, Java, ActiveX.

Отличия от классов объектов.

1. Невозможно образование экземпляров

2. не могут содержать свойств

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

4. Имеет методы проверки значений.

Коллекция

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

Коллекция массив: каждый элемент упорядочивается по ключу.

Коллекция список: в качестве ключа выступает позиция элемента.

Значение

Методы – операции, которые может выполнять объект. Каждый аргумент имеет имя, параметры и т. д.

Бывают методы экземпляра и методы класса (static)

Виды методов:

Code – содержит код на языке ObjectScript.

Expression – содержит одно выражение. При компиляции все вызовы метода заменяются этим выражением.

Запросы – могут быть представлены в виде хранимых процедур SQL или представлений. Результаты доступны через специальный интерфейс.

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

Объектное понятие

Реляционное

Экземпляр

идентификатор объекта

свойство константа

внешний ключ

встраиваемый объект

индивидуальные столбцы

коллекция список

столбец с полем-списком

коллекция массив

Подтаблица

поток данных

хранимая процедура

метод класса

хранимая процедура

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

32. Universe

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

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

Недостатки: сложность решения проблемы целостности и непротиворечимости данных.

33. Хранилище данных

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

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

Рисунок

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

Концепция баз данных, используемых в АИВС

Раздел 2

Контрольные вопросы

1.Что такое данные, информация, знания?

2.Дайте определение базы данных (БД).

3.Каково назначение БД?

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

5.Дайте определения понятиям «предметная область», «приложение», «про­грамма», ЯОД, ЯМД.

6.Дайте классификацию СУБД и БД.

7.Охарактеризуйте состав СУБД.

8.Покажите соотношение СУБД и АБД.

9.Перечислите процедуры работы БД.

10.Назовите составляющие теории баз данных.

11.Перечислите основные элементы структуры БД с позиций ее реализации.

12.Каково назначение OLTP и OLAP? соотношение их свойств?

13.Опишите состав OLAP.

14.Назовите разновидности многомерной модели.

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

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

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

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

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

2. Высокое быстродействие (малое время отклика на запрос).
Время отклика - промежуток времени от момента запроса к БД и
фактическим получением данных. Похожим является термин время
доступа - промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом пони­
мается операция поиска, чтения данных или записи их.

3. Независимость данных.

4. Совместное использование данных многими пользователями.

5. Безопасность данных - защита данных от преднамеренного
или непреднамеренного нарушения секретности, искажения или
разрушения.

6. Стандартизация построения и эксплуатации БД (фактически
СУБД).

8.Дружелюбный интерфейс пользователя.

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

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

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

Она предполагает:

Отсутствие неточно введенных данных или двух одинаковых
записей об одном и том же факте;

Защиту от ошибок при обновлении БД;

Невозможность удаления порознь (каскадное удаление) свя­занных данных разных таблиц;

Неискажение данных при работе в многопользовательском ре­
жиме и в распределенных базах данных;

Сохранность данных при сбоях техники (восстановление данных).

Целостность обеспечивается триггерами целостности - специ­альными приложениями-программами, работающими при опреде­ленных условиях. Для некоторых СУБД (например, Access, Paradox) триггеры являются встроенными.

Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может дости­гаться:

Введением системы паролей;

Получением разрешений от администратора базы данных (АБД);

Запретом от АБД на доступ к данным;

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

Три последние процедуры легко выполняются в рамках языка структурированных запросов Structured Query Language - SQL, час­то называемом SQL2.

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковы­ми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользова­теля СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент-сервер или сете­вой вариант).

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

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

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

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

К хранилищам данных предъявляются следующие дополнитель­ные требования:

Высокая производительность загрузки данных из операционных БД;

Возможность фильтрования, переформатирования, проверки
целостности исходных данных, индексирования данных, обновле­ния метаданных;

Повышенные требования к качеству исходных данных в части
обеспечения их непротиворечивости, поскольку они могут быть
получены из разных источников;

Высокая производительность запросов;

Обеспечение высокой размерности;

Одновременность доступа к ХД;

Наличие средств администрирования.

Поддержка анализа данных соответствующими методами (инст­рументами).

Э.Ф. Кодд на основе своего опыта предъявил следующие требования к системе OLAP.

1.Многомерное концептуальное представление данных.

2.Прозрачность технологии и источников данных.

3.Доступность к источникам данных при использовании различных моделей данных.

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

5. Использование гибкой, адаптивной, масштабируемой архитектуры клиент-сервер.

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

7. Динамическое управление разреженностью матриц (пустые
значения NULL должны храниться эффективным образом).

8. Многопользовательская поддержка.

9. Неограниченные операционные связи между размерностями.

10.Поддержка интуитивно понятных манипуляций с данными.

11.Гибкость средств формирования отчетов.

12.Неограниченное число измерений и уровней обобщения.

Перечисленные требования отличны от требований к операци­онным БД, что вызвало появление специализированных БД - хра­нилищ данных.

КОНСПЕКТ ОБЗОРНОЙ ЛЕКЦИИ

Для студентов специальности
Т1002 «Программное обеспечение информационных технологий»

(Л.В. Рудикова, к.ф.-м.н., доцент)

Вопрос 31. АРХИТЕКТУРА СУБД. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

1. Понятие базы данных.

2. Трехуровневая архитектура базы данных.

3. Жизненный цикл базы данных.

4. Архитектура СУБД.

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

6. Проектирование реляционных баз данных.

7. Нормальные формы отношений.

8. Реляционная алгебра.

1. Понятие базы данных.

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

Информационная система – автоматическая система, организующая данные и выдающая информацию.

Информационно-управляющая система – система, обеспечивающая информационную поддержку менеджмента.

Данные – разрозненные факты.

Информация – организованные и обработанные данные.

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

Каждая СУБД должна удовлетворять следующим требованиям:

· обеспечивать пользователю возможность создавать новые БД и определять их схему (логическую структуру данных) с помощью специального языка - языка определения данных ; поддерживать разнообразные представления одних и тех же данных;

· позволять «запрашивать » данные и изменять их с помощью языка запросов , или языка манипулирования данными ; допускать интеграцию и совместное использование данных различными приложениями;

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

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

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

· Пользователи, т.е. люди, которые используют данные.

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

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

· Данные, т.е. строки, хранящиеся в файлах.

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

Таким образом, систему с БД можно представить в виде следующей последовательности уровней:

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

2. Трехуровневая архитектура базы данных.

Различие между логическим и физическим представлением данных официально признано в 1978 году, когда комитет ANSI / SPARC предложил обобщенную структуру систем баз данных. Эта структура получила название трехуровневой архитектуры. Три уровня архитектуры следующие: внутренний, концептуальный и внешний.

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

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

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

Представления пользователей и приложений

Внешний уровень

Отображения

Концептуальная схема

Концептуальный уровень

Отображение

Внутренний уровень

Система-хост

Хранящиеся данные

Рис. Уровни СУБД

3. Жизненный цикл базы данных.

Процесс проектирования, реализации иподдержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

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

ЖЦБД состоит из следующих этапов:

1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:

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

· какие файлы связаны с каждым из этих приложений;

· какие новые приложения и файлы находятся в процессе работы.

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

Информация этого этапа документируется в виде обобщенной модели данных.

2. Проверка осуществимости . Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

· технологическая осуществимость – есть ли технология для реализации запланированной БД?

· операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

· экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

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

· Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

· Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.

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

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

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

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

5. Реализация процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:

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

· определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;

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

· спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;

· разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;

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

· разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

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

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.

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

Таким образом, ЖЦБД включает в себя:

· Изучение предметной области и представление соответствующей документации (1-3).

· Построение инфологической модели (4).

· Реализация (5).

· Оценка работы и поддержка БД (6).

4. Архитектура СУБД.



Рис. Главные компоненты СУБД

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

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

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

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

· Менеджер файлов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу менеджера буфера (диск в общем случае делится на дисковые блоки - смежные области памяти, содержащие от 4000 до 16000 байт).

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

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

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

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

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

Как правило, система БД поддерживает одновременно множество транзакций. Именно правильное выполнение всех таких транзакций и обеспечивает менеджер транзакций . Правильное выполнение транзакций обеспечивается ACID -свойствами (atomicity , consistency , isolation , durability ):

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

· непротиворечивость - состояние, при котором данные соответствуют всем возможным ожиданиям (например, условие непротиворечивости для БД авиационных линий состоит в том, что ни одно из мест в самолете не бронируется для двух пассажиров);

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

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

Рассмотрим также 3 типа обращения к СУБД:

1. Запросы - вопросы по поводу данных могут генерироваться двумя способами:

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

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

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

3. Модификации схемы - это команды администраторов БД, которые имеют право изменять схему БД или создавать новую БД.

Архитектура клиент/сервер. Во многих вариантах современного ПО реализуется архитектура клиент/сервер : один процесс (клиент) посылает запрос для выполнения другому процессу (серверу). Как правило, БД часто разделяется на процесс сервера и несколько процессов клиента.

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

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

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

Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Математически под N -арным отношением R понимают множество декартова произведения D 1 D 2 … D n множеств (доменов ) D 1, D 2 , …, D n (), необязательно различных:

R D 1 D 2 … D n ,

где D 1 D 2 … D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется их своего домена.

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

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

· Домен определен на некотором простом типе данных или на другом домене.

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

· Домен несет определенную смысловую нагрузку .

Атрибут отношения есть пара вида <Имя_атрибута: Имя_домена>. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.

Отношение R , определенное на множестве доменов, содержит две части: заголовок и тело.

Заголовок отношения – это фиксированное количество атрибутов отношения:

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

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута: Значение_атрибута>:

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

Отношение обычно записывается в виде:

или короче

,

или просто

Число атрибутов в отношении называют степенью (или -арностью ) отношения. Мощность множества кортежей отношения называют мощностью отношения.

Схемой отношения называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

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

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

Пусть – схема отношения . – схема отношения после упорядочения имен атрибутов. Тогда

Таким образом, для эквивалентных отношений выполняются следующие условия:

· Таблицы имеют одинаковое количество столбцов.

· Таблицы содержат столбцы с одинаковыми наименованиями.

· Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.

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

Все такие таблицы есть различные изображения одного и того же отношения.

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

· В отношении нет одинаковых кортежей .

· Кортежи не упорядочены (сверху вниз) .

· Атрибуты не упорядочены (слева направо) .

· Все значения атрибутов атомарны .

Рис. Схематическое изображение отношения

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

6. Проектирование реляционных баз данных.

При проектирование реляционной БД должны быть решены следующие проблемы:

1) С учетом семантики предметной области необходимо наилучшим способом представить объекты предметной области в виде абстрактной модели данных (даталогическое проектирование). Т.е. - определиться со схемой БД: из каких отношений должны состоять БД, какие атрибуты должны быть у этих отношений, каковы связи между отношениями.

2) Обеспечить эффективность выполнения запросов к базе данных (физическое проектирование БД).

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

· Построение корректной схемы данных ориентируясь на реляционную модель данных.

· Описание схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности БД.

· Разработка процедур поддержки семантической целостности БД.

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

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

Проектирование схемы БД можно выполнить двумя методами:

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

· Метод синтеза компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.

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

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

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

В теории реляционных БД обычно выделяют следующие нормальные формы:

первая нормальная форма (1 NF );

· вторая нормальная форма (2 NF );

· третья нормальная форма (3 NF );

· нормальная форма Байса-Кодда (BCNF );

· четвертая нормальная форма (4 NF );

· пятая нормальная форма или форма проекции - соединения (5 NF или PYNF ).

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

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

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

7. Нормальные формы отношений.

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

· Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.

· Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.

· Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.

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

Нормализация – разбиение таблицы на несколько, которые обладают лучшими свойствами при обновлении, вставке и удалении данных. Т.е. нормализация представляет собой процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ, однако, на практике достаточно привести таблицы к НФБК.

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

Если заменить на время нормализации коды первичных (внешних) ключей, то следует рассмотреть 2 случая:

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

Заменить , первичный ключ , ФЗ

на , первичный ключ

и , первичный ключ .

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

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

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

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

Если потенциальный ключ является простым, то отношение автоматически находится в 2НФ.

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

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

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

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

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

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

Если отношение находится в НФБК, то оно автоматически находится в 3НФ, что следует из определения 4. Чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, следует провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение.

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

Опр.5. Отношение находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей.

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

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

Опр.6. Отношение находится в пятой нормальной форме (5НФ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

Опр.6. тождественно также следует определению.

Опр.7. Отношение не находится в 5НФ, если в отношении найдется нетривиальная зависимость соединения.

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

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

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

Взаимно-независимые атрибуты это атрибуты, не зависящие один от другого. Если в отношение существует несколько ФЗ, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения.

9. Реляционная алгебра.

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

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

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

· определение (именованных) виртуальных отношений , т.е. представление данных для их визуализации через представления;

· определение снимка, т.е. определение данных для сохранения в виде «мгновенного снимка» отношения;

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

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

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

В реализациях конкретных реляционных СУБД сейчас не используется в чистом виде ни реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к реляционным данным стал язык SQL (Structured Query Language).

Реляционная алгебра, определенная Коддом состоит из 8 операторов, составляющих 2 группы:

  • традиционные операции над множествами (объединение, пересечение, вычитание, декартово произведение);
  • специальные реляционные операции (выборка, проекция, соединение, деление).

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

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

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

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

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

Объединение возвращает отношение, содержащее все кортежи, которые принадлежат или одному из двух определенных отношений, или обоим.

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

Вычитание – возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух определенных отношений и не принадлежат второму.

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

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

ЛИТЕРАТУРА

1. Дейт К.Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. – 848 с.

2. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.

3. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

4. Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. – М.: «Нолидж», 1999. – 560 с.

5. Дж. Грофф, П.Вайнберг. SQL: Полное руководство: Пер. с англ. – К.: Издательская группа BHV, 2001. – 816 с.

6. Кен Гетц, Пол Литвин, Майк Гилберт. Access 2000. Руководство разработчика. Т.1, 2. Пер. с англ. – К.: Издательская группа BHV, 2000. – 1264 с, 912 c.

7. Маклаков С.В BPwin и EPwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001. – 304 с.

8. Ульман Д., Уидом Д. Введение в системы баз данных / Пер. с англ. – М.: «Лори», 2000. – 374 с.

9. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д.Хомоненко. – Спб.: КОРОНА принт, 2000. – 416 с.

Правильно спроектированная БД должна удовлетворять следующим требованиям:

Минимальная избыточность. Непротиворечивость.

Целостность данных.

Независимость данных.

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

Безопасность и секретность.

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

Соблюдение стандартов.

1. Минимальная избыточность означает то, что данные в БД не должны дублироваться. Избыточность данных, если она существует, влечет две опасности:

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

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

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

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

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

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

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

Существуют специальные методы и приемы обеспечения целостности.

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

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

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

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

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

3. Независимость данных означает то, что прикладные программы не должны зависеть от хранимых данных, т.е. от способа хранения данных в физической памяти. Это позволяет добавлять в БД новые данные, изменять структуры хранения данных, создавать на БД новые приложения. Ранее созданные программы при этом не должны "чувствовать" эти изменения.

СУБД обычно обеспечивают это требование.

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

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

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

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

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

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

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

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

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