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

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

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

Безопасность данных включает их целостность и защиту.

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

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

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

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

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

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

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

Целостность обеспечивается триггерами целостности - специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:

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

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

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

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

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

Концепция построения БД

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

Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства - MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных (рис. 2.1, а) было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.

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

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

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

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

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

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

Пример 2.1. Задача ставится следующим образом. Имеется система ручных документов, форма одного из которых показана в табл. 2.1.

Таблица 2.1.

Данные о поставках

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

Таблица 2.2.

Отчет о поставках за квартал

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

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

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

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

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

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

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

Методология проектирования баз данных

Существует много разновидностей методологии рассмотрения баз данных в классическом подходе , однако чаще всего придерживаются методологии ANSI/SPARC, схема которой представлена на рис. 2.5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основными причинами низкой эффективности проектируемых БД могут быть:

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

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

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

Методология использования баз данных

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

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

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

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

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.Неограниченное число измерений и уровней обобщения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.1.

Определение основных терминов

Дадим определения основных терминов. В качестве составных частей схемы выделяются информация (входная и выходная) и правила ее преобразования.

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

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

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

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

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

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

Наряду с понятием "база данных" существует термин " банк данных ", который имеет две трактовки.

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

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

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

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

Основные требования, предъявляемые к банкам данных

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

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

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

• Сохранение затрат умственного труда: существующие программы и логические структуры данных не должны переделываться при внесении изменений в базу данных.
• Наличие интерфейса прикладного программирования: прикладные программы должны иметь возможность просто и эффективно выполнять запросы на данные; программы должны быть изолированными от расположения файлов и способов адресации данных.
• Распределенная обработка данных: система должна функционировать в условиях вычислительных сетей и обеспечивать эффективный доступ пользователей к любым данным распределенной БД, размещенным в любой точке сети.
• Адаптивность и расширяемость: база данных должна быть настраиваемой, причем настройка не должна вызывать перезаписи прикладных программ. Кроме того, поставляемый с СУБД набор предопределенных типов данных должен быть расширяемым - в системе должны иметься средства для определения новых типов и не должно быть различий в использовании системных и определенных пользователем типов.
• Контроль целостности данных: система должна осуществлять контроль ошибок в данных и выполнять проверку взаимного логического соответствия данных.
• Восстановление данных после сбоев: автоматическое восстановление без потери данных транзакции. В случае аппаратных или программных сбоев система должна возвращаться к некоторому согласованному состоянию данных.
• Вспомогательные средства должны позволять разработчику или
• Лингвистические средства;
• Программные средства;
• Технические средства;
• Организационно-административные подсистемы и нормативно-методическое обеспечение.

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

Пользователи БД и СУБД

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

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

1. анализ предметной области, статуса информации и пользователей;
2. проектирование структуры и модификация данных;
3. задание и обеспечение целостности;
4. защита данных;
5. обеспечение восстановления БД;
6. сбор и статистическая обработка обращений к БД, анализ эффективности функционирования БД;
7. работа с пользователем.

Краткие итоги

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

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

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

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

Вопросы для самопроверки

• Дайте определение базы данных.
• Дайте определение банка данных.
• Назовите две трактовки банка данных.
• Что такое система управления базой данных?
• Основные требования, предъявляемые к банку данных.
• Что такое данные, информация, знания?
• Пользователи СУБД и БД?
• Основные функции администратора БД.
• Что обеспечивает возможность быстрой и дешевой разработки новых приложений?

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

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

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

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

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

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

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

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

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