Многомерная модель данных

Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий

Интернет-Университет Информационных Технологий

Классификация знаний.

Составляющие базы знаний.

1. База данных, содержащая факты

2. БД, содержащая правила

3. Программное обеспечение, управляющее БЗ (СУБЗ), позволяющие выводить правила, управляющие данными.

1. Структурные – знания о зависимости между данными и ограничения на них.

2. Общие процедурные знания – знания которые можно описать только при помощи процедуры.

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

4. Знания предприятий – это внутренняя информация на предприятии.

   
 
 
 

https://www.INTUIT.ru

Базы данных
1. Лекция: Введение в базы данных. Общая характеристика основных понятий: версия для печати и PDA Лекция посвящена рассмотрению развития основных понятий обработки данных, связанного с постоянным расширением классов решаемых на ЭВМ задач. Показывается необходимость интеграции данных при решении несколькими пользователями задач, использующих общие данные. Вводится понятие базы данных.
Цель лекции: показать, что с изменением вида решаемых на ЭВМ задач в программировании возникают новые виды представления данных, в том числе такой вид, как базы данных. 1.1. Развитие основных понятий представления данных Любой вычислительный процесс представляет собой отображение (по определенному алгоритму) некоторых входных данных в выходные. Соотношение сложности представления обрабатываемых данных и алгоритма вычислений определяет два класса задач:
  • вычислительные задачи – достаточно простое представление данных и сложный, многооперационный процесс вычислений;
  • задачи обработки данных (невычислительные задачи) – простой алгоритм обработки данных и сложное представление обрабатываемых данных.
На начальной стадии обучения программированию основное внимание уделяется разработке алгоритма решения задачи. Однако часто оказывается, что возможность (или невозможность) решения конкретной задачи зависит не только от выбранного алгоритма, но и от того, какие понятия используются для представления обрабатываемых данных. Рассмотрим простейший пример вычисления по формуле: Y=X2+5X, где X и Y – определенные числа, которые являются здесь элементарными единицами данных (элементами данных). При программировании алгоритма решения этой задачи (программирование формулы) используется простейший вид данных – простая переменная (X и Y представляются в программе простыми переменными). Заметим, что простая переменная в системах программирования характеризуется определенным типом ее значений, которые должны выбираться при программировании. Даже в этом простейшем случае необходимо правильно выбрать тип переменной, причем от этого выбора может зависеть возможность или невозможность решения конкретной прикладной задачи (например, для представления конкретных данных не хватит отведенных разрядов). Рассмотрим другой пример: S=a1+a2+...+aN. Решение этой задачи в общем случае невозможно получить используя только простые переменные. Здесь обрабатывается не отдельное число, а последовательность чисел. В этом случае при программировании используется такой вид данных, как массив – совокупность элементов, с каждым из которых связан упорядоченный набор целых чисел, называемых индексами. Все элементы должны иметь одинаковый тип их значений, который и будет типом массива. В этом случае числа a1, a2,..., aN представляются в программе массивом A(1), A(2),..., A(N). Приведенные примеры показывают, что изменение вида задач обусловливает необходимость использования других видов данных. Ранние языки программирования (ФОРТРАН, АЛГОЛ-60) были предназначены для решения научно-технических вычислительных задач. В этих языках использовались только вышеуказанные виды данных (простые переменные и массивы) что было вполне достаточно. Начиная с конца 60-х годов компьютеры начинают интенсивно использоваться для решения так называемых невычислительных задач, связанных с обработкой различного рода документов. Рассмотрим появление новых видов данных на примере упрощенных задач обработки данных. Задача 1. Начисление заработной платы. Рассматриваем задачу при двух упрощающих предположениях:
  • сотруднику начисляется заработная плата на основе его оклада;
  • никакие налоги и вычеты не учитываются.
Необходимые для решения этой задачи сведения о сотруднике представлены в следующей карточке НАЧИСЛЕНИЕ:
Фамилия, имя, отчество Оклад Количество отработанных дней в месяц Начисленная сумма
FIO O Ko S

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

S=KoO/Kr,

где Kr – количество рабочих дней в данном месяце.

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

Иванов Иван Иванович      

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

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

Элемент данных (поле) – наименьшая единица поименованных данных.

Для данного примера элементами данных являются FIO, O, Ko, S.

Для описания карточки сотрудника используется понятие " Логическая запись ".

Логическая запись – поименованная совокупность элементов данных (полей).

Экземпляр логической записи – текущее значение элементов записи.

Для представления всего набора карточек сотрудников используется понятие " Логический файл "

Логический файл - поименованная совокупность всех экземпляров записей заданного типа.

Пример логического файла НАЧИСЛЕНИЕ:

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

В алгоритмическом языке Паскаль вводится такой вид данных, как запись (RECORD) – сложная переменная с несколькими компонентами, которые могут иметь разные типы. Кроме того, доступ к компонентам записи (полям) осуществляется не по индексу, а по имени. При программировании задачи 1 на языке Паскаль логическая запись НАЧИСЛЕНИЕ представляется видом данных RECORD, набор экземпляров логических записей сотрудников (логический файл) представляется "физическим" файлом, формируемым средствами языка Паскаль и операционной системы.

Salary = RECORD FIO: string; O: real; Ko: real; S: real;END;

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

В связи с этим решение задачи 1 состоит из двух этапов.

1. Ввод исходных данных и занесение их во внешнюю память.

typeSalary = RECORDFIO: string;O: real;Ko: real;S: real;END;FSalary = File of Salary;var F: FSalary;...{ Ввод исходных данных }repeat write('Введите количество сотрудников (не более', MaxN,'): '); readln(N);until (N>0) AND (N<=MaxN);For I:= 1 to N doBegin Write('Введите фамилию сотрудника с номером ',I,': '); ReadLn(Sotr[i].FIO); Write('Введите оклад сотрудника с номером ', I, ': '); ReadLn(Sotr[i].O); Write('Введите кол-во отработанных дней сотрудника с номером ', I, ': '); ReadLn(Sotr[i].Ko);End; { Занесение данных во внешнюю память } Assign(F, 'MyFile.fsf');Rewrite(F);For I:= 1 to N do Write(F, Sotr[i]);Close(F);...

2. Чтение исходных данных из внешней памяти, расчет начисленных сумм и вывод на печать.

...{ Чтение данных из внешней памяти }Assign(F, 'MyFile.fsf');Reset(F);For I:= 1 to N do Read(F, Sotr[i]);Close(F);{ Расчет и печать начисленных сумм }For I:= 1 to N doBegin Sotr[i].S:= Sotr[i].O * Sotr[i].Ko / Kr; WriteLn(Sotr[i].FIO, ': ', Sotr[i].S);End;...

Представленные программы решают поставленную задачу при сделанных предположениях. Необходимые для этого данные хранятся в файле MyFile.fsf, предназначенном только для решения этой задачи. Отметим, что в этом случае описание данных включено в прикладную программу. При изменении формата записей файла необходимо изменение прикладной программы. Таким образом, программная система, решающая поставленную задачу, определяет свои собственные данные и управляет ими. Такие программные системы называются файловыми системами [[2]], [[3]].

Задача 2. Учет кадрового состава.

Здесь обрабатываются сведения о сотруднике, представленные в карточке СОТРУДНИК:

Фамилия, имя, отчество Должность Год рождения Оклад Место жительства
FIO D G O M

Решение задачи состоит из следующих этапов:

Ввод исходных данных и занесение их во внешнюю память.

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

...{ Чтение данных из внешней памяти }Assign(F, 'MyFile.fsf');Reset(F);IsFound:= False;For I:= 1 to N doBegin Read(F, Sotr); If Sotr.FIO = KeyFio Then Begin IsFound:= True; Sotr.D:= 'Начальник отдела'; Seek(F, FilePos(F)-1); Write(F, Sotr); Break; End;If IsFound Then WriteLn('Корректировка успешно произведена')Else WriteLn('Сотрудника ', KeyFio, 'не обнаружено');Close(F);...

В рассматриваемом случае задача 2 решается независимо от задачи 1.

Задача 3. Учет экономии фонда оплаты труда (ФОТ) в связи с болезнью сотрудников.

Обрабатываются сведения, представленные записями ЭКОНОМИЯ ФОТ:

Фамилия, имя, отчество Оклад Количество дней на больничном листе Невыплаченная сумма
FIO O Kдв SN
SN=KдвO/Kr.

Программа решения задачи 3 аналогична программе решения задачи 1.

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

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

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

FIO D O G Ko M Kдв S SN

Дублирование информации полностью убрано. Расход памяти минимален. Недостатки устранены. Рассмотрим, как в этом случае изменится время решения задач 1–3. Время решения задачи прямо пропорционально объему считываемых из внешней памяти данных.

Обозначим Ti, li, Ni соответственно время решения, длину записи, число записей i-й задачи (i = 1, 2, 3) при использовании отдельных файлов для каждой задачи:

Ti≈C*li*Ni

где C – некоторый коэффициент пропорциональности.

Обозначим Ri, d, N соответственно время решения i-й задачи (i = 1, 2, 3) при использовании файла объединенных записей, длину записи, число записей:

Ri≈C*d*N

Заметим, что N1 = N2 = N, N3 << N.

Тогда время решения i-й задачи (i = 1, 2) при использовании объединенного файла увеличится в Ri/Ti≈d/li раз. Для нашего примера время решения задач в зависимости от выбранной длины полей может изменяться в 2–3 раза. Таким образом, платой за исключение дублирования информации является увеличение времени решаемых задач. Заметим, что такое увеличение, как правило, допустимо.

Время решения задачи 3 увеличится в R3/T3≈d*N/l3*N3 раз. Так как для данного примера N3 << N, то R3 >> T3. Время решения задачи 3 может увеличиться на несколько порядков, что совершенно недопустимо.

Рассмотрим другой вариант построения единой информационной базы. Объединим записи задач 1 и 2, запись задачи 3 оставим отдельно. Получим два типа записей:

FIO D O G Ko S M
FIO O Kдв SN
                 

В этом случае дублирование остается (дублируются поля FIO, O). Но так как N3<<N, то общий объем дублирования незначителен. Время решения задачи 1 и 2 в этом случае незначительно возрастет по сравнению с вариантом отдельных файловых систем, время решения задачи 3 такое же, как и в начальном варианте отдельного файла. Такое объединение позволяет значительно уменьшить влияние недостатков и в то же время существенно увеличивает время решения всех задач. Все три задачи можно решать, используя общую информационную базу из двух типов записей. Отметим, что два приведенных типа записей связаны друг с другом по полю FIO (находятся в некотором отношении). Отметим, что приведенные варианты интеграции не исчерпывают все возможные способы интеграции данных для приведенных задач и к вопросу выбора наилучшего варианта вернемся в последующих лекциях.

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

Для описания этого вида данных вводится новое понятие " База данных " [[1]].

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

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

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

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

© INTUIT.ru, 2003-2010. Все права защищены.

https://www.INTUIT.ru

Базы данных
2. Лекция: Системы управления базами данных: версия для печати и PDA Вводится понятие системы управления базами данных (СУБД). Дается характеристика основных функций системы управления базами данных
Цель лекции: показать необходимость создания программного интерфейса между прикладными программами и базой данных, определить понятие системы управления базами данных и сформулировать основные функции СУБД, вытекающие из задачи взаимодействия многих пользователей с базой данных. В прикладной программе, использующей при решении задачи один или несколько отдельных файлов, за сохранность и достоверность данных отвечал программист, работающий с этой задачей. Использование базы данных предполагает работу с ней нескольких прикладных программ, решающих задачи разных пользователей. Естественно, что за сохранность и достоверность интегрированных данных программист, решающий одну из прикладных задач, отвечать уже не может. Кроме того, расширение круга решаемых с использованием базы данных задач может приводить к появлению новых типов записей и отношений между ними. Такое изменение структуры базы данных не должно вести к изменению множества ранее разработанных и успешно функционирующих прикладных программных систем, работающих с базой данных. С другой стороны, возможное изменение любой из прикладных программ, в свою очередь, не должно приводить к изменению структуры данных. Все вышесказанное обусловливает необходимость отделения данных от прикладных программ. Роль интерфейса между прикладными программами и базой данных, обеспечивающего их независимость, играет программный комплекс – система управления базами данных (СУБД) (рис. 2.1). СУБД – программный комплекс поддержки интегрированной совокупности данных, предназначенный для создания, ведения и использования базы данных многими пользователями (прикладными программами). Рис. 2.1. Обеспечение независимости прикладных программ и базы данных Определим еще одно понятие. Банк данных – система языковых, алгоритмических, программных, технических и организационных средств поддержки интегрированной совокупности данных, а также сами эти данные, представленные в виде баз данных. Перечислим основные функции системы управления базами данных. 1. Определение структуры создаваемой базы данных, ее инициализация и проведение начальной загрузки. Как правило, создание структуры базы данных происходит в режиме диалога. СУБД последовательно запрашивает у пользователя необходимые данные. В большинстве современных СУБД база данных представляется в виде совокупности таблиц. Рассматриваемая функция позволяет описать и создать в памяти структуру таблицы, провести начальную загрузку данных в таблицы. Примеры таких действий для СУБД MS Access приведены на рисунке 2.2. увеличить изображение Рис. 2.2. Формирование структуры базы данных в СУБД Access 2. Предоставление пользователям возможности манипулирования данными (выборка необходимых данных, выполнение вычислений, разработка интерфейса ввода/вывода, визуализация). Такие возможности в СУБД представляются либо на основе использования специального языка программирования, входящего в состав СУБД, либо с помощью графического интерфейса. В MS Access реализация данной функции может быть реализована созданием запросов и форм ввода с помощью графического интерфейса (рис. 2.3). увеличить изображение Рис. 2.3. Формирование запроса на выборку в СУБД Access Для клиент-серверных СУБД существуют средства, позволяющие выполнять запросы, и программные средства, позволяющие создавать графический интерфейс пользователя. 3. Обеспечение независимости прикладных программ и данных (логической и физической независимости). Важнейшим свойством СУБД является возможность поддерживать два независимых взгляда на базу данных – "взгляд пользователя", воплощаемый в логическом представлении данных, и его отражения в прикладных программах; и "взгляд системы" – физическое представление данных в памяти ЭВМ. Обеспечение логической независимости данных предоставляет возможность изменения (в определенных пределах) логического представления базы данных без необходимости изменения физических структур хранения данных. Таким образом, изменение логического представления данных в прикладных программах не приводит к изменению структур хранения данных. Обеспечение физической независимости данных предоставляет возможность изменять (в определенных пределах) способы организации базы данных в памяти ЭВМ не вызывая необходимости изменения "логического" представления данных. Таким образом, изменение способов организации базы данных не приводит к изменению прикладных программ. 4. Защита логической целостности базы данных. Основной целью реализации этой функции является повышение достоверности данных в базе данных. Достоверность данных может быть нарушена при их вводе в БД или при неправомерных действиях процедур обработки данных, получающих и заносящих в БД неправильные данные. Для повышения достоверности данных в системе объявляются так называемые ограничения целостности, которые в определенных случаях "отлавливают" неверные данные. Так, во всех современных СУБД проверяется соответствие вводимых данных их типу, описанному при создании структуры. Система не позволит ввести символ в поле числового типа, не позволит ввести недопустимую дату и т.п. В развитых системах ограничения целостности описывает программист, исходя из содержательного смысла задачи, и их проверка осуществляется при каждом обновлении данных. Более подробно разные аспекты логической целостности базы данных будут рассматриваться в последующих разделах. 5. Защита физической целостности. При работе ЭВМ возможны сбои в работе (например, из-за отключения электропитания), повреждение машинных носителей данных. При этом могут быть нарушены связи между данными, что приводит к невозможности дальнейшей работы. Развитые СУБД имеют средства восстановления базы данных. Важнешим используемым понятием является понятие " транзакции ". Транзакция – это единица действий, производимых с базой данных. В состав транзакции может входить несколько операторов изменения базы данных, но либо выполняются все эти операторы, либо не выполняется ни один. СУБД, кроме ведения собственно базы данных, ведет также журнал транзакций. Необходимость использования транзакций в базах данных проиллюстрируем на упрощенном примере. Предположим, что база данных используется в некотором банке и один из клиентов желает перевести деньги на счет другого клиента банка. В базе данных хранится информация о количестве денег у каждого из клиентов. Нам нужно сделать два изменения в базе данных – уменьшить сумму денег на счете одного из клиентов и, соответственно, увеличить сумму денег на другом счете. Конечно, реальный перевод денег в банке представляет собой гораздо более сложный процесс, затрагивающий много таблиц, а возможно, и много баз данных. Однако суть остается та же – нужно либо совершить все действия (увеличить счет одного клиента и уменьшить счет другого), либо не выполнить ни одно из этих действий. Нельзя уменьшить сумму денег на одном счете, но не увеличить сумму денег на другом. Предположим также, что после выполнения первого из действий (уменьшения суммы денег на счете первого клиента) произошел сбой. Например, могла прерваться связь клиентского компьютера с базой данных или на клиентском компьютере мог произойти системный сбой, что привело к перезагрузке операционной системы. Что в этом случае стало с базой данных? Команда на уменьшение денег на счете первого клиента была выполнена, а вторая команда – на увеличение денег на другом счете – нет,что привело бы к противоречивому, неактуальному состоянию базы данных. Использование механизма транзакций позволяет находить решение в этом и подобных случаях. Перед выполнением первого действия выдается команда начала транзакции. В транзакцию включается операция снятия денег на одном счете и увеличения суммы на другом счете. Оператор завершения транзакций обычно называется COMMIT. Поскольку после выполнения первого действия транзакция не была завершена, изменения не будут внесены в базу данных. Изменения вносятся (фиксируются) только после завершения транзакции. До выдачи данного оператора сохранения данных в базе не произойдет. В нашем примере, поскольку оператор фиксации транзакции не был выдан, база данных "откатится" в первоначальное состояние – иными словами, суммы на счетах клиентов останутся те же, что и были до начала транзакции. Администратор базы данных может отслеживать состояние транзакций и в необходимых случаях вручную "откатывать" транзакции. Кроме того, в очевидных случаях СУБД самостоятельно принимает решение об "откате" транзакции. Транзакции не обязательно могут быть короткими. Бывают транзакции, которые длятся несколько часов или даже несколько дней. Увеличение количества действий в рамках одной транзакции требует увеличения занимаемых системных ресурсов. Поэтому желательно делать транзакции по возможности короткими. В журнал транзакций заносятся все транзакции – и зафиксированные, и завершившиеся "откатом". Ведение журнала транзакций совместно с созданием резервных копий базы данных позволяет достичь высокой надежности базы данных. Предположим, что база данных была испорчена в результате аппаратного сбоя компьютера, на котором был установлен сервер СУБД. В этом случае нужно использовать последнюю сделанную резервную копию базы данных и журнал транзакций. Причем применить к базе данных нужно только те транзакции, которые были зафиксированы после создания резервной копии. Большинство современных СУБД позволяют администратору воссоздать базу данных исходя из резервной копии и журнала транзакций. В таких системах в определенный момент БД копируется на резервные носители. Все обращения к БД записываются программно в журнал изменений. Если база данных разрушена, запускается процедура восстановления, в процессе которой в резервную копию из журнала изменений вносятся все произведенные изменения. 6. Управление полномочиями пользователей на доступ к базе данных. Разные пользователи могут иметь разные полномочия по работе с данными (некоторые данные должны быть недоступны; определенным пользователям не разрешается обновлять данные и т.п.). В СУБД предусматриваются механизмы разграничения полномочий доступа, основанные либо на принципах паролей, либо на описании полномочий. 7. Синхронизация работы нескольких пользователей. Достаточно часто может иметь место ситуация, когда несколько пользователей одновременно выполняют операцию обновления одних и тех же данных. Такие коллизии могут привести к нарушению логической целостности данных, поэтому система должна предусматривать меры, не допускающие обновление данных другим пользователям, пока работающий с этими данными пользователь полностью не закончит с ними работать. Основным используемым здесь понятием является понятие " блокировка ". Блокировки необходимы для того, чтобы запретить различным пользователям возможность одновременно работать с базой данных, поскольку это может привести к ошибкам. Для реализации этого запрета СУБД устанавливает блокировку на объекты, которые использует транзакция. Существуют разные типы блокировок – табличные, страничные, строчные и другие, которые отличаются друг от друга количеством заблокированных записей. Чаще других используется строчная блокировка – при обращении транзакции к одной строке блокируется только эта строка, остальные строки остаются доступными для изменения. Таким образом, процесс внесения изменений в базу данных состоит из следующей последовательности действий: выдается оператор начала транзакции, выдается оператор изменения данных, СУБД анализирует оператор и пытается установить блокировки, необходимые для его выполнения, в случае успешной блокировки оператор выполняется, затем процесс повторяется для следующего оператора транзакции. После успешного выполнения всех операторов внутри транзакции выполняется оператор фиксации транзакции. СУБД фиксирует изменения, сделанные транзакцией, и снимает блокировки. В случае неуспеха выполнения какого-либо из операторов транзакция "откатывается", данные получают прежние значения, блокировки снимаются. 8. Управление ресурсами среды хранения. БД располагается во внешней памяти ЭВМ. При работе в БД заносятся новые данные (занимается память) и удаляются данные (освобождается память). СУБД выделяет ресурсы памяти для новых данных, перераспределяет освободившуюся память, организует ведение очереди запросов к внешней памяти и т.п. 9. Поддержка деятельности системного персонала. При эксплуатации базы данных может возникать необходимость изменения параметров СУБД, выбора новых методов доступа, изменения (в определенных пределах) структуры хранимых данных, а также выполнения ряда других общесистемных действий. СУБД предоставляет возможность выполнения этих и других действий для поддержки деятельности БД обслуживающему БД системному персоналу, называемому администратором БД. Краткие итоги. Рассмотрено понятие системы управления базами данных как интерфейса между прикладными программами и базами данных. Введено понятие банка данных. Дана характеристика основных функций систем управления базами данных, вытекающие из задачи взаимодействия многих пользователей с базой данных:
  • Определение структуры создаваемой базы данных, ее инициализация и проведение начальной загрузки
  • Предоставление пользователям возможности манипулирования данными (выборка необходимых данных, выполнение вычислений, разработка интерфейса ввода/вывода, визуализация).
  • Обеспечение независимости прикладных программ (логической и физической независимости).
  • Защита логической целостности базы данных.
  • Защита физической целостности.
  • Управление полномочиями пользователей на доступ к базе данных.
  • Синхронизация работы нескольких пользователей.
  • Управление ресурсами среды хранения.
  • Поддержка деятельности системного персонала.
Информация по содержанию данной лекции содержится в [[4],[2],[3]]
© INTUIT.ru, 2003-2010. Все права защищены.

https://www.INTUIT.ru

Базы данных
3. Лекция: Различные архитектурные решения, используемые при реализации многопользовательских СУБД. Краткий обзор СУБД: версия для печати и PDA В лекции рассматриваются различные варианты технологии работы с базой данных в многопользовательском режиме (централизованная архитектура, компьютерная сеть с файловым сервером, клиент-серверная архитектура). Дается краткий обзор современных СУБД.
Цель лекции: показать основные варианты технологии работы нескольких пользователей с одной базой данных, связанные как с основными свойствами вычислительной техники, так и с развитием программного обеспечения. Как уже отмечалось, понятие базы данных изначально предполагало возможность решения многих задач несколькими пользователями. В связи с этим, важнейшей характеристикой современных СУБД является наличие многопользовательской технологии работы. Разная реализация таких технологий в разное время была связана как с основными свойствами вычислительной техники, так и с развитием программного обеспечения. Дадим краткую характеристику этих технологий в хронологическом порядке. 3.1. Централизованная архитектура При использовании этой технологии база данных, СУБД и прикладная программа (приложение) располагаются на одном компьютере (мэйнфрейме или персональном компьютере) (рис.3.1.). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе. Работа построена следующим образом:
  • База данных в виде набора файлов находится на жестком диске компьютера.
  • На том же компьютере установлены СУБД и приложение для работы с БД.
  • Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
  • Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.
  • СУБД инициирует обращения к данным, обеспечивая выполнение запросов пользователя (осуществляя необходимые операции над данными).
  • Результат СУБД возвращает в приложение.
  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Рис. 3.1. Централизованная архитектура Подобная архитектура использовалась в первых версиях СУБД DB2, Oracle, Ingres [[5]]. Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнении их программ). Такая технология была распространена в период "господства" больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей. 3.2. Технология с сетью и файловым сервером (архитектура "файл-сервер") Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры файл-сервер. Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных [[6]]. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных (рис. 3.2.). Рис. 3.2. Архитектура "файл-сервер" Работа построена следующим образом:
  • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).
  • Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.
  • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
  • Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.
  • СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).
  • При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.
  • Результат СУБД возвращает в приложение.
  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
В рамках архитектуры " файл-сервер " были выполнены первые версии популярных так называемых настольных СУБД, таких, как dBase и Microsoft Access. В литературе [[6]] указываются следующие основные недостатки данной архитектуры:
  • При одновременном обращении множества пользователей к одним и тем же данным производительность работы резко падает, т.к. необходимо дождаться пока пользователь, работающий с данными, завершит свою работу. В противном случае возможно затирание исправлений, сделанных одними пользователями, изменениями других пользователей.
  • Вся тяжесть вычислительной нагрузки при доступе к БД ложится на приложение клиента, так как при выдаче запроса на выборку информации из таблицы вся таблица БД копируется на клиентскую машину и выборка осуществляется на клиенте. Таким образом, неоптимально расходуются ресурсы клиентского компьютера и сети. В результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера.
  • Как правило, используется навигационный подход, ориентированный на работу с отдельными записями.
  • В БД на файл-сервере гораздо проще вносить изменения в отдельные таблицы, минуя приложения, непосредственно из инструментальных средств (например, из утилиты Database Desktop фирмы Borland для файлов Paradox и dBase); подобная возможность облегчается тем обстоятельством, что фактически у таких СУБД база данных – понятие более логическое, чем физическое, поскольку под БД понимается набор отдельных таблиц, сосуществующих в отдельном каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений.
  • Недостаточно развитый аппарат транзакций служит потенциальным источником ошибок в плане нарушения смысловой и ссылочной целостности информации при одновременном внесении изменений в одну и ту же запись.
3.3. Технология "клиент – сервер" Использование технологии " клиент – сервер " предполагает наличие некоторого количества компьютеров, объединенных в сеть, один из которых выполняет особые управляющие функции (является сервером сети). Так, архитектура " клиент – сервер " разделяет функции приложения пользователя (называемого клиентом) и сервера. Приложение-клиент формирует запрос к серверу, на котором расположена БД, на структурном языке запросов SQL (Structured Query Languague), являющемся промышленным стандартом в мире реляционных БД. Удаленный сервер принимает запрос и переадресует его SQL-серверу БД. SQL-сервер – специальная программа, управляющая удаленной базой данных. SQL-сервер обеспечивает интерпретацию запроса, его выполнение в базе данных, формирование результата выполнения запроса и выдачу его приложению-клиенту. При этом ресурсы клиентского компьютера не участвуют в физическом выполнении запроса; клиентский компьютер лишь отсылает запрос к серверной БД и получает результат, после чего интерпретирует его необходимым образом и представляет пользователю. Так как клиентскому приложению посылается результат выполнения запроса, по сети "путешествуют" только те данные, которые необходимы клиенту. В итоге снижается нагрузка на сеть. Поскольку выполнение запроса происходит там же, где хранятся данные (на сервере), нет необходимости в пересылке больших пакетов данных. Кроме того, SQL-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами [[6], [7]]. Архитектура системы представлена на рис. 3.3. Все это повышает быстродействие системы и снижает время ожидания результата запроса. При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый SQL-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно [[6], [7]]. Рис. 3.3. Архитектура "клиент – сервер" Итак, в результате работа построена следующим образом:
  • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
  • СУБД располагается также на сервере сети.
  • Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлено клиентское приложение для работы с БД.
  • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к СУБД, расположенной на сервере, на выборку/обновление информации. Для общения используется специальный язык запросов SQL, т.е. по сети от клиента к серверу передается лишь текст запроса.
  • СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
  • СУБД инициирует обращения к данным, находящимся на сервере, в результате которых на сервере осуществляется вся обработка данных и лишь результат выполнения запроса копируется на клиентский компьютер. Таким образом СУБД возвращает результат в приложение.
  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Рассмотрим, как выглядит разграничение функций между сервером и клиентом.
  • Функции приложения-клиента:
    • Посылка запросов серверу.
    • Интерпретация результатов запросов, полученных от сервера.
    • Представление результатов пользователю в некоторой форме (интерфейс пользователя).
  • Функции серверной части:
    • Прием запросов от приложений-клиентов.
    • Интерпретация запросов.
    • Оптимизация и выполнение запросов к БД.
    • Отправка результатов приложению-клиенту.
    • Обеспечение системы безопасности и разграничение доступа.
    • Управление целостностью БД.
    • Реализация стабильности многопользовательского режима работы.
В архитектуре " клиент – сервер " работают так называемые "промышленные" СУБД. Промышленными они называются из-за того, что именно СУБД этого класса могут обеспечить работу информационных систем масштаба среднего и крупного предприятия, организации, банка. К разряду промышленных СУБД принадлежат MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, InterBase и ряд других [[6]]. Как правило, SQL-сервер обслуживается отдельным сотрудником или группой сотрудников (администраторы SQL-сервера). Они управляют физическими характеристиками баз данных, производят оптимизацию, настройку и переопределение различных компонентов БД, создают новые БД, изменяют существующие и т.д., а также выдают привилегии (разрешения на доступ определенного уровня к конкретным БД, SQL-серверу) различным пользователям [[6]]. Рассмотрим основные достоинства данной архитектуры по сравнению с архитектурой "файл-сервер":
  • Существенно уменьшается сетевой трафик.
  • Уменьшается сложность клиентских приложений (большая часть нагрузки ложится на серверную часть), а, следовательно, снижаются требования к аппаратным мощностям клиентских компьютеров.
  • Наличие специального программного средства – SQL-сервера – приводит к тому, что существенная часть проектных и программистских задач становится уже решенной.
  • Существенно повышается целостность и безопасность БД.
К числу недостатков можно отнести более высокие финансовые затраты на аппаратное и программное обеспечение, а также то, что большое количество клиентских компьютеров, расположенных в разных местах, вызывает определенные трудности со своевременным обновлением клиентских приложений на всех компьютерах-клиентах. Тем не менее, архитектура " клиент – сервер " хорошо зарекомендовала себя на практике, в настоящий момент существует и функционирует большое количество БД, построенных в соответствии с данной архитектурой. 3.4. Трехзвенная (многозвенная) архитектура "клиент – сервер". Трехзвенная (в некоторых случаях многозвенная) архитектура (N-tier или multi-tier). представляет собой дальнейшее совершенствование технологии " клиент – сервер ". Рассмотрев архитектуру " клиент – сервер ", можно заключить, что она является 2-звенной: первое звено – клиентское приложение, второе звено – сервер БД + сама БД. В трехзвенной архитектуре вся бизнес-логика (деловая логика), ранее входившая в клиентские приложения, выделяется в отдельное звено, называемое сервером приложений. При этом клиентским приложениям остается лишь пользовательский интерфейс. Так, в качестве клиентского приложения в описанном выше примере выступает Web-браузер. Что улучшается при использовании трехзвенной архитектуры? Теперь при изменении бизнес-логики более нет необходимости изменять клиентские приложения и обновлять их у всех пользователей. Кроме того, максимально снижаются требования к аппаратуре пользователей. Итак, в результате работа построена следующим образом:
  • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (сервера сети).
  • СУБД располагается также на сервере сети.
  • Существует специально выделенный сервер приложений, на котором располагается программное обеспечение (ПО) делового анализа (бизнес-логика) [[5]].
  • Существует множество клиентских компьютеров, на каждом из которых установлен так называемый "тонкий клиент" – клиентское приложение, реализующее интерфейс пользователя.
  • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение – тонкий клиент. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к ПО делового анализа, расположенному на сервере приложений.
  • Сервер приложений анализирует требования пользователя и формирует запросы к БД. Для общения используется специальный язык запросов SQL, т.е. по сети от сервера приложений к серверу БД передается лишь текст запроса.
  • СУБД инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на сервере.
  • СУБД инициирует обращения к данным, находящимся на сервере, в результате которых результат выполнения запроса копируется на сервер приложений.
  • Сервер приложений возвращает результат в клиентское приложение (пользователю).
  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
3.5. Краткий обзор СУБД Многие авторы классифицируют СУБД на две большие категории: так называемые "настольные" и "серверные". 3.5.1. Настольные СУБД Настольные СУБД используются для сравнительно небольших задач (небольшой объем обрабатываемых данных, малое количество пользователей). С учетом этого, указанные СУБД имеют относительно упрощенную архитектуру, в частности, функционируют в режиме файл-сервер, поддерживают не все возможные функции СУБД (например, не ведется журнал транзакций, отсутствует возможность автоматического восстановления базы данных после сбоев и т. п.). Тем не менее, такие системы имеют достаточно обширную область применения. Прежде всего, это государственные (муниципальные) учреждения, сфера образования, сфера обслуживания, малый и средний бизнес. Специфика возникающих там задач заключается в том, что объемы данных не являются катастрофически большими, частота обновлений не бывает слишком высокой, организация территориально обычно расположена в одном небольшом здании, количество пользователей колеблется от одного до 10–15 человек. В подобных условиях использование настольных СУБД для управления информационными системами является вполне оправданным, и они с успехом применяются. Одними из первых СУБД были так называемые dBase-совместимые программные системы, разработанные разными фирмами. Первой широко распространенной системой такого рода была система dBase III – PLUS (фирма Achton-Tate). Развитый язык программирования, удобный интерфейс, доступный для массового пользователя, способствовали широкому распространению системы. В то же время работа системы в режиме интерпретации обусловливала низкую производительность на стадии выполнения. Это привело к появлению новых систем-компиляторов, близких к системе dBase III – PLUS: Clipper (фирма Nantucket Inc.), FoxPro (фирма Fox Software), FoxBase+ (фирма Fox Software), Visual FoxPro (фирма Microsoft). Одно время достаточно широко использовалась СУБД PARADOX (фирма Borland International). В последние годы очень широкое распространение получила система управления базами данных Microsoft Access, которая входит в целый ряд версий пакета Microsoft Office(фирма Microsoft). 3.5.2. Серверные СУБД Для крупных организаций ситуация принципиально меняется. Там использование файл-серверных технологий является неудовлетворительным по описанным выше причинам. Поэтому на передний край борьбы за автоматизацию выходят так называемые серверные СУБД. Основными производителями таких систем обработки и хранения данных являются 3 корпорации: Oracle, Microsoft и IBM. Диаграмма соотношения объемов продаж соответствующих систем (источник: IDC Report, Май 2006) приводится на рис. 3.4. Рис. 3.4. Продажи ПО систем хранения данных в мире Наиболее распространенными клиент-серверными системами здесь соответственно являются системы Oracle (разработчик компания Oracle), MS SQL Server (разработчик компания Microsoft), DB2, Informix Dynamic Server (компания IBM). Дадим краткую характеристику этим системам. MS SQL Server К настоящему времени разработано несколько версий систем: MS SQL Server-2000, MS SQL Server -2005, MS SQL Server-2008. Приведем информацию о системе MS SQL Server-2008 с сервера Microsoft (https://www.microsoft.com/rus/SQL/2008/default.mspx) Microsoft® SQL Server™ 2008 - это законченное предложение в области баз данных и анализа данных для быстрого создания масштабируемых решений электронной коммерции, бизнес-приложений и хранилищ данных. Оно позволяет значительно сократить время выхода этих решений на рынок, одновременно обеспечивая масштабируемость, отвечающую самым высоким требованиям. В SQL Server включена поддержка языка XML и протокола HTTP, средства повышения быстродействия и доступности, позволяющие распределить нагрузку и обеспечить бесперебойную работу, функции для улучшения управления и настройки, снижающие совокупную стоимость владения. Платформа бизнес-анализа SQL Server 2008, тесно интегрированная с Microsoft Office, предоставляет развитую маштабируемую инфраструктуру для внедрения мощных возможностей бизнес-анализа в рабочий процесс всех бизнес-подразделений вашей компании, открывая доступ к нужной бизнес-информации через знакомый интерфейс MS Excel и MS Word. MS SQL Server-2008 поддерживает создание и работу с корпоративным хранилищем данных, объединяющим информацию со всех систем и приложений, позволяющим получить единую комплексную картину бизнеса вашей компании. MS SQL Server-2008 предоставляет масштабируемый и высокопроизводительный "процессор данных" - для самых ответственных и требовательных бизнес-приложений, тем, кому необходим высочайший уровень надежности и защиты, позволяя при этом снизить совокупную стоимость владения за счет расширенных возможностей по управлению серверной инфраструктурой. MS SQL Server-2008 предлагает разработчикам развитую, удобную и функциональную среду программирования, включая средства работы с веб службами, инновационные технологии доступа к данным – все, что необходимо для эффективной работы с данными любых типов и форматов. Отдельные аспекты MS SQL Server – 2008 будут описаны в лекциях 10 и "Направления развития баз данных"14. Oracle К настоящему времени разработано несколько версий систем, каждая из которых включает целую линейку продуктов, например Oracle 8, Oracle 9i, Oracle 10g. Соответствующие линейки продуктов включают как собственно СУБД (например Oracle Database 10g, Oracle Database 11g), так и средства разработки и анализа данных. Приведем информацию о системе с сервера Oracle https://www.oracle.com/global/ru/mid/oracle_products/database.html). Oracle предлагает комплексные, открытые, доступные и удобные в использовании технологические решения. Готовые пакетируемые решения автоматически включают в свою стоимость базу данных, сервер приложений, интеграционную платформу, инструменты аналитики и управления неструктурированными данными. Масштабируемые бизнес-приложения Oracle могут быть легко интегрированы с ИТ-инфраструктурой предприятия без потери уже вложенных в IT инвестиций. СУБД Oracle Database 11g обеспечивает улучшенные характеристики за счет автоматизации задач администрирования и обеспечения лучших в отрасли возможностей по безопасности и соответствию нормативно-правовым актам в области защиты информации. Появилось больше функций автоматизации, самодиагностики и управления. Среди характеристик системы можно отметить управление большими объемами данных с использованием распределенных таблиц и компрессии, эффективную защиту данных, возможность полного восстановления, возможность интеграции геофизических данных медиа-контента в бизнес-процеcc и т.д. Серверы баз данных компании IBM К настоящему времени разработаны линейки продуктов DB2 и Informix, включающая как собственно СУБД так и средства разработки и анализа данных (DB2 Universal Database DB2 Personal Edition, DB2 Enterprise 9 и др., а также Informix Dynamic Server, Informix Dynamic Server Express, Informix Extended Parallel Server и др. Приведем информацию о части таких систем с сервера (https://www-01.ibm.com/software/ru/data/?pgel=ibmhzn) Универсальный сервер баз данных DB2 Universal Database - это масштабируемая, обьектно-реляционная система управления базами данных с интегрированной поддержкой мультимедиа и Web, работающая на системах от персональных компьютеров и серверов на процессорах Intel до Unix, от однопроцессорных систем до симметричных многопроцессорных систем (SMP) и систем с массовым параллелизмом (MPP), на хостах AS/400 и мейнфреймах. DB2 Universal Database объединяет в себе высокую производительность систем обработки транзакций в режиме on-line, объектно-реляционные расширения, усовершенствованные средства оптимизации с возможностями параллельной обработки и поддержкой очень больших баз данных. DB2 Universal Database также имеет новые встроенные средства для облегчения переноса на свою базу приложений, разработанных на других системах управления базами данных, таких как Oracle, Microsoft, Sybase и Informix. Помимо этого, DB2 Universal Database включает в себя дополнительные средства поддержки систем аналитической обработки в реальном времени (OLAP) и систем поддержки принятия решений, множество простых в использовании расширений (DB2 extenders). DB2 Universal Database доступна на абсолютном большинстве ключевых платформ, что дает заказчикам ту гибкость, которая им необходима. Кроме вышеуказанных зарубежных систем отметим и отечественную разработку – СУБД НИКА, преемницу широко распространенной в Советском Союзе СУБД ИНЕС для ЕС ЭВМ. Краткие итоги. В лекции рассмотрены различные архитектурные решения, используемые при реализации многопользовательских СУБД. Централизованная архитектура. Технология с сетью и файловым сервером (архитектура " файл-сервер "). Архитектура " клиент – сервер " (распределенная модель вычислений). Трехзвенная (многозвенная) архитектура клиент – сервер. Дан обзор современных СУБД (настольные СУБД, серверные СУБД).
© INTUIT.ru, 2003-2010. Все права защищены.

https://www.INTUIT.ru

Базы данных
4. Лекция: Различные представления о данных в базах данных. Основные этапы проектирования баз данных: версия для печати и PDA В лекции рассматриваются различные представления о данных в базах данных. Описываются модели данных (внешнее представление, концептуальная модель, структура хранения) и основные этапы проектирования базы данных. Рассматривается жизненный цикл проектирования базы данных.
Цель лекции: Показать существование различных представлений о данных (различных моделей) у разных групп лиц, работающих с данными. Рассмотреть отражение этих представлений в трехуровневой архитектуре базы данных (внешний уровень, концептуальный уровень, внутренний уровень), сформулировать достоинство трехуровней архитектуры. Выделить основные этапы проектирования базы данных как процесса построения вышеуказанных моделей. 4.1. Различные представления о данных в базах данных Создание базы данных предполагает интеграцию данных, предназначенных для решения нескольких прикладных задач разных пользователей. Соответственно, при интеграции данных должны учитываться требования к данным каждого пользователя, основанные на его представлении о данных и связях между ними. Далее эти требования должны обобщаться в единое представление, которое и будет служить основой для построения единой базы данных (рис. 4.1). Обобщение представлений всех пользователей о данных называется концептуальной моделью (схемой) БД. Концептуальная модель представляет информационное описание предметной области с учетом логических взаимосвязей, поэтому её еще называют инфологической (информационно-логической) моделью. В модели отсутствуют какие-либо понятия, связанные с ЭВМ, памятью ЭВМ, способами размещения данных в памяти ЭВМ, и, по сути, это модель только предметной области. Рис. 4.1. Обобщение представления пользователей о данных Как

Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow