Базы данных

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

1. система БД

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

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

Назначение СУБД:

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

обеспечить секретность и разграничение прав доступа к информации;

защита целостности и непротиворечивость данных. Например, контроль, что число проданных билетов не превышало числа мест в самолете;

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

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

2. Основные компоненты СУБД: данные, аппаратура, ПО, пользователи

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

данные;

аппаратное обеспечение;

программное обеспечение;

пользователи.

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

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

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

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

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

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

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

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

На больших предприятиях в настоящее время все чаще используются два вида БД:

операционная БД - для поддержания повседневной работы предприятия;

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

Аппаратное обеспечение:

накопители;

сетевое оборудование;

оперативная память

процессор.

Программное обеспечение:

СУБД;

утилиты;

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

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

генераторы счетов и др.

Пользователи:

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

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

Администраторы базы данных организуют и отвечают за работу с БД.



3. Уровни абстракции в СУБД

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

Самая жизнеспособная архитектура организации базы данных была предложена группой ANSI/X3/SPARC Study Group, которая была организована в 1972 г. комитетом Standards Planning and Requirements Committee (SPARC) института American National Standards Institute on Computers and Information Processing (ANSI/X3). Эта архитектура имеет трехуровневую систему организации базы данных.

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

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

уровень

Внутренний (физический)

уровень

Трехуровневая система организации базы данных

Таким образом, существуют три уровня абстракции в архитектуре базы данных:

представление (внешняя модель базы данных);

концептуальная база данных (КБД);

физическая база данных (ФБД).

При проектировании базы данных процесс перехода от реальности к информационной модели происходит в несколько этапов:

1. Внешняя модель или уровень представления. На этом уровне предметная область (т.е. та область деятельности, в которой осуществляется разработка данной системы) описывается будущим пользователем БД. Каждый пользователь описывает свое представление о предметной области. При этом, описывается: какие объекты важны в работе пользователя, какими свойствами они обладают, связи между объектами, прочие правила взаимодействия объектов.

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

язык, описывающий деревья (иерархическая модель);

язык сетей, как класса графов (сети, сетевая модель).

язык отношений (реляционная модель);

ER - модели, как вариант языка сетевой модели.

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

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

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

4. Данные. Схемы и экземпляры БД

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

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

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

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

Для описания схем и экземпляров используют следующие понятия:

Хранимое поле - это наименьшая единица хранимых данных. БД может содержать много экземпляров одного из нескольких типов полей (ФИО, №Детали).

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

Пример:

запись о детали (номер, название, вес, цвет и т.д.).

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

5. Схемы уровня представлений

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

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

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

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

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



6. Модели типа объект/отношение. (Понятие ER-модель)

Модели БД типа объект/отношение могут быть использованы на всех уровнях абстракции.

Особенности модели. Ее преимущества и недостатки.

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

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

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

Пример: объектами являются: сотрудник, пассажир, самолет, деталь и т.д. 

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

Пример: подчиненный сотрудник ? основной сотрудник.

Различают тип объекта и экземпляр объекта

Пример: тип - сотрудник; экземпляр - Иванов.

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

Пример: объект -- сотрудник, его атрибуты: ФИО, дата рождения...

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

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

Пример: объект студент, ключ - номер зачетной книжки.

7. Виды связей. Диаграммы объектов / связей

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

Пример: между объектами деталь и поставщик может возникнуть связь - деталь_поставляется_поставщиком (для каждого экземпляра поставщика ставится в соответствие список деталей, которые он поставляет).

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

Рассмотрим виды связей на примере базы данных «Хирургическое отделение больницы». Выделим четыре типа объектов: Место_в_палате, Палата, Пациент, Хирург.

Между объектами могут возникать следующие связи:

один к одному 1:1 (Пациент - Место_в_палате);

один к многим 1:n, или, как вариант - многие к одному n:1 (Палата - Место_в_палате);

многие к многим n:n (Пациент - Хирург).

Диаграммы объектов / связей.

8. Концептуальная схема и её модели данных

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

Для определения базы данных на концептуальном уровне СУБД предоставляет так называемый язык определения данных (DDL - data definition language). Этот язык позволяет записать концептуальную схему в терминах некоторой модели данных. В качестве модели данных может быть выбрана, например, модель объектов/отношений. Преимущество и недостатки этой модели рассмотрены выше. Основными понятиями этой модели являются понятия объект, атрибуты (свойства), отношения (связи).

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

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

Модели, которые используются для описания концептуальных схем:

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

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

Типичным представителем СУБД, в которой реализована иерархическая модель, является СУБД IMS фирмы IBM (INFORMATION MANGMENT SYSTEM) середина 60-х годов. Эта СУБД официально считается вообще первой реализованной СУБД. Распространение этого типа СУБД объясняется простотой и наглядностью используемой модели, которая широко распространена в различных областях деятельности человека и в природе (государство, армия, предприятия, стая и т.д.). Недостатком этой СУБД является сложность реализация связей n:n(многие к многим).

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

Теоретические основы модели разработаны независимой ассоциацией CODASYL, как обобщение иерархической модели и опыта эксплуатации информационных систем. Ассоциация образованна в конце 50-х годов и финансировалась Пентагоном с целью разработки алгоритмического языка, ориентированного на экономические задачи (COBOL - Common Bisnes Oriented language). Разработчикам этого языка принадлежит ряд пионерских решений в области разработки алгоритмических языков и в частности языков для обработки информации. Это:

прозрачность текста программы для неспециалиста (синтаксис близкий к обычному языку, длинные идентификаторы, выражения и операции типа «умножить количество на цену получая сумму» {как совокупность разных типов});

понятие структуры (как тип в языке программирования);

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

Язык COBOL считается прототипом (предшественником) СУБД. В конце 60-х годов в рамках CODASYL была организованна рабочая группа по базам данных (Data Base Task Group - DBTG), отчеты которой за 1969...75 годы являются основной теорией БД и в частности сетевых БД. Так DBTG предложило ввести три уровня абстракции, этот подход был позже стандартизован институтом стандартов US (ANSI) и известен как архитектура ANSI/SPARC. Большинство теоретических разработок группы DBTG были стандартизованы.

Известны несколько СУБД сетевой структуры: CA-IDMS/BD компания Computer Associates International Inc, в СССР - ИНЕС.

Реляционная модель. Базируется на теоретико - множественном понятии отношения. Модель разработана американским математиком Коддом (Codd), сотрудником фирмы IBM и опубликована в 1970 г. В настоящее время является наиболее полно разработанной основой теории БД. В настоящем курсе будет рассмотрена теория реляционных БД.

Примеры реляционных СУБД: DB/2 фирмы IBM, ORACLE корпорация Oracle, SYBASE компания Sybase Inc. К реляционным относятся свободно распространяемые СУБД: MySQL и PostgreSQL.

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

В настоящее время ведутся в направлении так называемых «постреляционных» СУБД. Назовем некоторые из них:

дедуктивные СУБД;

экспертные СУБД;

расширяемые СУБД;

объектно-ориентированные СУБД;

семантические СУБД;

универсальные реляционные СУБД.

9. Внутренняя (физическая) схема БД

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

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

10. Соотношение внутреннего и внешнего языка определения данных

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

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

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

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

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

В настоящее время существует один язык, который поддерживается практически всеми СУБД это язык SQL (Structured Query Language).

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

СУБД с сильно связанными языками сложнее разработать, но очевидна существенная тенденция продвижения к более сильно связанным системам. Подъязык данных на самом деле является комбинацией двух языков: языка определения данных (data definition language - DDL), который поддерживает объявление или определение объектов БД, и языка обработки данных (data manipulation lаnguage - DML), который поддерживает операции с такими объектами или их обработку.

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

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

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

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

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

Уровни абстракции архитектуры СУБД.

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

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

Пример: некоторое приложение работает с хранимым файлом, в котором описаны два поля «А» и «В». Если этот файл заменить на другой, в котором хранимые поля переставлены местами («В» и «А»), то это изменение структуры записи хранимого файла не приведет к нарушению работы данного приложения.

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

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

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

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

12. Администратор баз данных

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

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

Создание схем представлений.

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

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

Взаимодействие с пользователями:

- предоставления пользователям полномочий на использование БД или её частей;

- помощь пользователям в разработке схем представлений;

- определение соответствия между схемами представления и концептуальной схемой;

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

Определение правил безопасности и целостности. Т.е. описание условий непротиворечивости и ограничений в доступе к файлам БД.

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

Управление производительностью и реагирование на изменяющиеся требования:

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

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

13. Функции СУБД

Определение данных.

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

Обработка данных.

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

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

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

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

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

Безопасность и целостность данных.

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

Восстановление данных и дублирование.

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

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

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

Обеспечение производительности.

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

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



14. Архитектура клиент/сервер

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

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

Клиент - это различные приложения, которые выполняются «над» СУБД.

Типы приложений:

приложения, написанные пользователем;

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

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

Исключением являются специальные ''служебные'' приложения, которые работают на внутреннем уровне системы. Такие приложения (утилиты) скорее относятся к компонентам СУБД. Рассмотрим подробнее типы приложений:

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

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

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

генераторы отчетов, т. е. системы визуализации результатов построенных запросов;

графические бизнес - системы;

электронные таблицы;

процессоры обычных языков программирования;

средства управления копированием;

генераторы приложений;

другие средства разработки приложений, включая CASE-продукты (COMPUTER AIDED SOFTWARE ENGINEERING);

системы автоматизация разработки программного обеспечения.

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

15. Распределенная обработка

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

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

Распределенная обработка.

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

Термин клиент/сервер - фактически синоним такой схемы.

Преимущества такой схемы:

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

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

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

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

Пример: работы БД банка:

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



В последнем случае распределение информации, более точно описывает структуру предприятия. Доступ возможен двумя способами: Клиент может получить доступ к любому числу серверов, но лишь к одному в одно и тоже время. В этом случае нет возможности за один запрос получить комбинацию данных с двух и более серверов, кроме того, приложение «должно знать» на какой машине, какая часть данных содержится. При втором способе клиент получает доступ к любому числу серверов одновременно (возможны комбинации) в этом случае все серверы рассматриваются клиентом как один логический сервер и пользователь «может не знать» на какой именно машине, какая часть данных содержится. Такая реализация прозрачна для клиента, но сложна в реализации. Именно этот случай (последний рисунок) называется распределенной системой БД.

16. Двухзвенная модель распределение функций в модели клиент/сервер

В БД выполняются 3 основные функции: управление данными, обработка и представление. Если эти 3 функции делятся между 2 ЭВМ, то говорят о двухзвенной модели клиент/сервер

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

Преимущество: простота обслуживания, т.к все описание на сервере.

Недостаток: уязвимость центрального компьютера

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

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

3. распределенная функция.

Преимущество: повышение эффективности использования клиент ЭВМ.

Недостаток: сложность поддержки

4. удаленный доступ к данным по отношению к клиенту.

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

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

5. распределенная БД. Возможны два варианта реализации: локальная + удаленная БД хранимая как одно целое; - локальная БД является копиями удаленных (репрекация БД) - работа с локальной и синхронизации с удаленной.

Преимущества: гибкость создаваемой информационной системы; высокая живучесть.

Недостатки: затраты на приложения; нужен механизм синхронизации.

Доступ серверам возможен 2-мя способами:

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

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

17. Модель организации внешней памяти

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

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

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

прочитать блок, который её содержит;

найти в оперативной памяти запись внутри блока.

При таком подходе запись внутри блока можно перемещать, при этом указатель на запись (фактически указатель на блок её содержащий) не изменится. Уменьшается вероятность «зависания указателя» - это когда «указатель» указывает на место, где записи на самом деле нет.

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

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

18. Закрепленные и незакрепленные записи

Для определения стратегии реализации файлов важно, являются ли записи файла «закрепленными» по некоторому фиксированному адресу, или нет.

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

При закреплении записей мы не можем перемещать записи об этих объектах, иначе указатели на них «зависнут», т.е. не будут указывать на данные, на которые они указывали первоначально.

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

19. Организация файлов в виде кучи

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

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

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

Удаление может осуществляться установкой специального бита для каждой записи (признак удаления) в состояние «удалено».

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

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

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

20. Хешированные файлов

Основной принцип организации хешированных файлов.

Решается задача: по ключу найти запись.

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

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

При выборе функции h желательно, чтобы h(v) принимала все её возможные значения (от 0 до N) примерно с равной вероятностью, когда v принимает всевозможные допустимые значения ключа.

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

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

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

Складываем полученные группы бит как целые числа.

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

Пример: >как распределяется остаток от деления. m>n остаток [0, … n-1].

Схема организации хешированного файла.

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

Рассмотрим структуру блока:

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

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

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

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

в блоке отводят 1 бит на каждый субблок. Его нулевое значение - субблок свободен, 1- субблок занят.

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

Организация поиска в хешированном файле.

Задача: найти запись с ключом v. (v- одно поле или список полей в фиксированном порядке- тогда v конкатенация полей).

Вычислим h(v) получая номер участка i. Прочтём справочник участков и найдем адрес первого блока участка i. Читаем первый блок, анализируем субблоки на совпадение ключа. Если найдено - поиск успешен - конец. Если нет - читаем следующий блок данного участка. Если его нет - поиск не успешно.

5. Модификация в хешированном файле

Задача: изменить одно или несколько полей записи с ключом v.

Найти запись с ключом v. Если не найдена - аварийный останов.

Найдена запись:

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

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

6. Включение в хешированном файл

Задача: добавить запись с ключом v.

Найти запись с ключом v (вычисляется номер участка, куда надо добавить запись). Если запись найдена, аварийный останов. Иначе:

Найдем первый свободный субблок среди блоков участка h(v) (этот субблок может быть в середине, если ранее было удаление с освобождением субблока, т.е. записи не закреплены). Адрес этого субблока можно запомнить при поисках ключа v. Помещаем запись в данный субблок > записываем блок на место. Если свободного места нет > получаем свободный блок из OС. Организуем цепочку с последним блоком участка h(v) > пишем блок на диск.

Удаление в хешированном файле.

Задача: удаление записи с ключом v.

Найти запись с ключом v. Если не найдена, то аварийный останов. Иначе: