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

ПОНЯТИЕ И КЛАССИФИКАЦИЯ БАЗ ДАННЫХ

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

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

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

Рис. 7.4. Обобщенная схема использования БД для решения задач пользователей

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

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

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

Интересно, что название одной из известнейших в мире террористических группировок «Al-Quaeda» (Аль-Кайеда) в переводе с арабского языка означает «База данных». Происхождение этого названия вызвано строгим учетом сведений о членах организации.

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

К основным свойствам баз данных и средств их поддержки и организации можно отнести:

- отсутствие дублирования данных, обеспечивающее однократный ввод данных и простоту их корректировки;

- непротиворечивость данных;

- целостность базы данных;

- возможность многоаспектного доступа;

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

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

- защита данных от несанкционированного доступа средствами разграничения доступа для различных пользователей;

- возможность модификации структуры БД без повторной загрузки данных;

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

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

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

Рис. 7.5. Классификация баз данных

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

Распределенные базы данных состоят из нескольких, возможно пе­ресекающихся или даже дублирующих друг друга частей, хранимых в различных персональных компьютерах ЛВС (кластерные БД). Однако пользователь распределенной базы данных получает возможность работать с ней как с единым информационным массивом с помощью специализированного программного обеспечения — системы управления базами данных (СУБД). Части распределенной БД, размещенные на отдельных ПК сети, управляются собственными локальными СУБД и могут использоваться одновременно как самостоятельные локальные базы данных. Причем, локальные СУБД могут быть различными на разных рабочих станция ЛВС.

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

2. По типу хранимых данных выделяют два основных вида БД:

- фактографические, содержащие краткие сведения об описываемых объектах, представленные в строго определенном формате;

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

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

3. По режимам доступа базы данных подразделяются на следующие виды:

1) базы данных с доступом в режиме online (online databases) хранятся в центральном банке данных. Доступ к ним осуществляется посредством телекоммуникационного оборудования и каналов связи. К таким базам данных можно отнести внутреннюю БД предприятия, имеющего ЛВС, корпоративное хранилище данных с доступом по каналам VPN, а также базы данных, расположенные в Internet (Internet databases). Обращаться к ним можно в режиме реального времени, извлекать из них сведения и сохранять их на компьютере или вспомогательном запоминающем устройстве;

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

4. По количеству пользователей БД выделяют следующие виды:

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

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

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

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

5. По обслуживанию базами данных решаемых задач выделяют два основных вида БД:

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

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

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

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

6. По форме организации данных выделяют:

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

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

7. По модели баз данных выделяют следующие виды БД:

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

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

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

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

- объектно-ориентированные, в которых данные оформлены в виде моделей объектов, включающих прикладные программы, управляющие внешними событиями;

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

- модель данных «объектов-ролей » включает в себя два основных понятия — «объекты» и «роли», над которыми выполняются манипуляции. Модель используется для понятийного моделирования и в настоящее время не получила широкого распространения;

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

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

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

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

- «один к одному» (1–1), когда одна запись может быть связана только с одной записью;

- «один ко многим» (1–М) – одна запись взаимосвязана со многими другими записями или многие записи взаимосвязаны только с одной записью (во втором случае эту связь также называют «многие к одному»);

- «многие ко многим» (М–М) – одна и та же запись может входить в отношения со многими другими записями в различных вариантах.

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

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

В файловой модели для структурирования информации используется модель «плоский файл», имеющий линейную (одноуровневую) структуру и, представляющую собой двумерную таблицу. Для разработки плоских файлов не используются СУБД. Как правило, их разрабатывают в специализированном ПО.

К основным типам структур файловой модели относятся:

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

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

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

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

- Ключ записи – идентификатор, однозначно определяющий каждый экземпляр записи.

В моделях данных выделят два вида ключей – первичный и вторичный.

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

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

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

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

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

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

Рисунок 7.6 – Пример документа и его структуры

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

Иерархическая модель данных является наиболее простой и появилась первой среди всех моделей БД, организованных в среде СУБД. Появление иерархической модели связано с тем, что в различных областях человеческой деятельности очень многие связи соответствуют иерархии, когда один объект выступает как родительский, а с ним может быть связано множество подчиненных объектов. Самой известной иерархической системой позволяющей создавать иерархические БД является система IMS (Information Management System) фирмы IBM, используемая в свое время для поддержки лунного проекта «Аполлон» («Apollon»), в процессе реализации которого необходимо было управлять огромным количеством деталей, иерархически связанных между собой.

Иерархическая модель представляется в виде перевернутого дерева, в котором объекты выделяются по уровням соподчиненности (иерархии) объектов (см. рис. 7.7).

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

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

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

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

Рисунок 7.7 – Иерархическая модель данных

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

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

Рисунок 7.8 – Пример иерархической базы данных

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

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

Сетевая модель данных является развитием иерархической модели. Она появилась в 1971 г., когда группа DTBG (Database Task Group) представила в американский национальный институт стандартов отчет, который послужил в дальнейшем основой для разработки сетевых систем управления базами данных. Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference of Data System Languages), которая определила базовые понятия модели и формальный язык описания.

Структура БД в сетевой модели задается типами записей и типами наборов, которые представляют собой поименованную совокупность связанных записей. Сетевая модель данных основана на тех же основных понятиях (уровень, узел, связь), что и иерархическая, но в сетевой модели каждый узел может быть связан с любым другим узлом, т.е. взаимосвязи между элементами БД в сетевой модели организованы по типу «многие к одному» или «много ко многим». Примером сетевой БД можно назвать Internet. Гиперссылки связывают между собой сотни миллионов документов в единую распределенную сетевую базу данных.

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

Рисунок 7.9 – Сетевая модель данных

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

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

Рисунок 7.10 – Пример сетевой базы данных

К особенностям организации сетевой модели относятся:

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

- связь между двумя записями может выражаться произвольным количеством наборов;

- в любом наборе может быть только один владелец;

- тип записи может быть владельцем в одних типах наборов и членом в других типах наборов;

- тип записи может не входить ни в какой тип наборов.

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

К достоинствам сетевых моделей можно отнести:

- отсутствие дублирования данных в различных элементах модели;

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

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

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

Реляционная модель данных. Основателем реляционной модели является сотрудник фирмы IBM Э.Ф. Кодд, который в 1970 году в своей статье вывел заключение о том, что любое представление данных может быть сведено к совокупности двумерных таблиц, называемых в математике «отношениями» (relations – отношения). Отсюда и пошел термин, определяющий модель данных, представленную в виде таблиц – «реляционная».

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

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

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

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

Структурными объектами обработки реляционной БД являются следующие информационные единицы (см. рис. 7.11):

Рисунок 7.11 – Основные структурные элементы реляционной базы данных

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

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

Экземпляр записи – отдельная реализация записи, содержащая конкретные значения ее полей (конкретная строка реляционной таблицы).

Таблица (отношение) – заданная структура полей, состоящая из конечного набора однотипных записей.

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

- однозначная идентификация записи – запись должна однозначно определяться значением ключа;

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

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

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

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

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

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

Рисунок 7.12 – Реляционная БД поставки товаров по договорам

База данных состоит из шести таблиц – «Заказчики», «Данные о заказчике», «Договоры», «Изделия», «Заказы изделий», «Поставка изделий».

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

Таблица «Изделия» (рис. 7.12 б) содержит код поставляемых изделий и их номер.

Таблица «Данные о заказчике» (рис. 7.13 в) содержит контактные данные о заказчике (название организации и контактный телефон).

Таблица «Договоры» (рис. 7.12 г) описывает заключенные с заказчиками договоры и включает в себя код договора, код заказчика и номер заключенного договора.

В таблице «Заказы изделий» (рис. 7.12 д) отражено количество заказанных изделий по каждому договору.

В таблице «Поставка изделий» (рис. 7.12 е) отражено количество поставленных изделий по каждому заказу и дата отгрузки.

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

Рисунок 7.13 – Связи в таблицах реляционной базы данных

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

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

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

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

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

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

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

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

Первая нормальная форма (1NF):

- запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию);

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

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

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

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

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

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

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

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

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

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

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

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

установлена связь типа «один к одному» (см. рис. 7.14).

Рисунок 7.14 – Связь «один к одному» в таблицах реляционной БД

Этот тип связи используется достаточно редко, т.к. в этом случае данные двух таблиц могут быть объединены в одну таблицу. К причинам разбиения одной таблицы на несколько, связанных отношением «один к одному», можно отнести:

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

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

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

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

Например, рассмотренные таблицы «Договоры» и «Заказы изделий» находятся в отношении «один ко многим». При этом на стороне «один» находится таблица «Договоры», а на стороне «многие» – «Заказы изделий». Связь устанавливается по полю Код договора. Каждая запись таблицы «Договоры» может иметь много связанных с ней записей в таблице «Заказы изделий» (т.к. в данном случае по одному договору заказчикам поставляются несколько видов изделий), иначе говоря, в таблице «Заказы изделий» может быть много строк с заданным значением в поле Код договора (например, по различным кодам изделий). В то же время, если взять любую строку в таблице «Заказы изделий», то для нее найдется не более одной строки в таблице «Договоры» с таким же значением в поле Код договора (см. рис. 7.15).

Рисунок 7.15 – Связь «один ко многим» в таблицах реляционной БД

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

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

Такая связь всегда реализуется с помощью третьей (связующей) таблицы. Например, в рассмотренной выше задаче для связи таблиц «Договоры» и «Изделия» сформирована таблица «Заказы изделий» (см. рис. 7.16).

Рисунок 7.16 – Связь «многие ко многим» в таблицах реляционной БД

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

При этом если рассмотреть таблицы «Договоры» и «Заказы изделий», то между ними установлено отношение «один ко многим», в котором таблица «Договоры» является главной, а таблица «Заказы изделий» – подчиненной. Аналогично между таблицами «Изделия» и «Заказы изделий» установлена связь «один ко многим», в которой таблица «Изделия» является главной.

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

Базовые операции:

- ограничение – исключение из таблицы некоторых строк;

- проекция – исключение из таблицы некоторых столбцов;

- декартово произведение – из двух таблиц получается третья по принципу декартова произведения, когда результат содержит все атрибуты из таблиц-сомножителей (количество полей новой таблицы равно сумме количества полей в каждой из таблиц-сомножителей) и все возможные сочетания записей (количество записей в новой таблице равно произведению количества записей в таблицах-сомножителях). Например, умножив таблицу «Заказчики» на таблицу «Договоры» получим 6 полей и 9 записей. Потом оставляем только те записи, где код заказчика совпадает (3) и нужные нам поля. Таким способом получаем сведения о заказчиках для каждого договора;

- объединение – объединение множеств строк двух таблиц;

- разность – разность множеств строк двух таблиц;

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

Производные операции:

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

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

- деление позволяет отвечать на вопросы типа – какой элемент данных соответствует элементам определенного атрибута (столбца)? Например, какие заказчики приобретают изделие кода СТУ1432?

- разбиение позволяет отвечать на вопросы типа – какие несколько элемен-

- тов соответствуют элементам определенного атрибута (столбца)? Напри-

- мер, какие три заказчика приобретают изделие кода СТУ1432?

- расширение – добавление новых столбцов в таблицу;

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

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

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

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

- простота представления данных, благодаря табличной форме;

- гибкость системы защиты – для каждой таблицы может быть задана правомерность доступа;

- минимальная избыточность данных;

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

- универсальность процедур обработки данных.

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

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

Объектно-ориентированная модель данных (ООМД) – это один из вариантов расширенной реляционной модели.

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

В 1991 г. был образован консорциум ODMG (тогда эта аббревиатура означала Object Database Management Group – группа управления объектными базами данных, но впоследствии приобрела более широкую трактовку – Object Data Management Group – группа управления объектными данными). Консорциум ODMG тесно связан с гораздо более многочисленным консорциумом OMG (Object Management Group – группа управления объектами), который был образован двумя годами раньше. Основной исходной целью ODMG была выработка промышленного стандарта объектно-ориентированных баз данных (общей модели). За основу была принята базовая объектная модель OMG COM (Core Object Model – объектная модель документа). В течение своего существования ODMG опубликовала несколько базовых версий стандарта объектно-ориентированных баз данных.

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

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

Таблица 7.1 – Основные понятия объектно-ориентированной модели

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

Рисунок 7.17 – Пример логической структуры объектно-ориентированной БД

склада предприятия-поставщика изделий

На рис. 7.17 объект типа Склад является родительским для объектов классов Заказчик, Поставка и Изделие. Различные объекты типа Материал могут иметь одного или разных родителей. Объекты типа Материал, имеющие одного и того же родителя, должны различаться, например, видом материала (уникален для каждого материала), но имеют одинаковые значения свойства – Отделка.

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

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

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

Наследование, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Материал, являющимся потомками объекта типа Изделие, можно приписать свойства объекта-родителя: код, название, отделка и тип изделия. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств Кода и № поставки в объекте Склад приводит к наследованию этих свойств всеми дочерними объектами Заказчик, Поставка и Материал. Не случайно, поэтому значения свойства Кода заказчика классов Заказчик и Поставка являются одинаковыми – АО126.

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

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

К достоинствам объектно-ориентированной модели обычно относят:

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

- возможность отображения информации о сложных взаимосвязях объектов;

- возможность идентифицировать отдельные записи БД и определять функции их обработки;

- наличие наследуемости свойств объектов;

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

К недостаткам объектно-ориентированной модели можно отнести:

- отсутствие строгих определений – разное понимание терминов и различия в терминологии;

- недостаточная исследованность и теоретическая проработка модели;

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

- высокая понятийная сложность;

- низкая скорость выполнения запросов.

Объектно-реляционная модель данных совмещает в себе реляционную модель с методами объектно-ориентированного подхода.

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

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

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

К основным недостаткам объектно-реляционной модели являются:

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

- сложность терминологии;

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

- сравнительно низкая производительность и т.д.

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

Авторы документа «Системы баз данных третьего поколения: Манифест» (Второго манифеста) являлись представителями индустриально-ориентированных исследований. Второй манифест написан в более жестком стиле и во многом направлен на защиту инвестиций крупных компаний-производителей программного обеспечения SQL-ориентированных СУБД. Конечно, Второй манифест во многом представлял собой реакцию индустрии на революционные предложения Первого манифеста. Эти предложения подвергались критике, которая заключалась в том, что, можно добиться аналогичных результатов, не производя революцию в области технологии БД, а эволюционно развивая технологию SQL-ориентированных СУБД. «Третий манифест» являлся одновременно наиболее консервативным и наиболее радикальным. Консервативность Третьего манифеста заключается в том, что его авторы всеми силами утверждают необходимость и достаточность использования в системах БД следующего поколения классической реляционной модели данных. Радикальность состоит в том, что (a) авторы полностью отрицают подходы, предлагаемые в первых двух манифестах, расценивая их как необоснованные, плохо проработанные, избыточные и даже вредные. Фактически, авторы полностью отбрасывают технологию, созданную индустрией баз данных за последние 25 лет, и предлагают вернуться к истокам реляционной модели данных, т.е. к начальным статьям Э. Кодда, который в 1980 году за свою реляционную модель данных получил премию Тьюринга.

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

Модель данных «объектов-ролей» является моделью данных, имеющей конкретную программную реализацию – InfoModeller. Модель «объектов-ролей» была предложена еще в начале 70-х годов и в настоящее время реализуется фирмой Asymetrix. В отличие от реляционной модели в ней нет атрибутов, а основные понятия – это объекты и роли, описывающие их. Роли могут быть как «изолированные», присущие исключительно какому-нибудь объекту, так и существующие как элемент какого-либо отношения между объектами. Модель «объектов-ролей» отличается от реляционной следующими особенностями:

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

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

Модели «объектов-ролей» сейчас уделяется большое внимание специалистов, однако, до промышленных масштабов ее использования еще достаточно далеко.

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

- системы оперативной (транзакционной) обработки (OLTP-приложения);

- системы аналитической обработки (OLAP-приложения).

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

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

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

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

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

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

4. Согласованная производительность. Производительность практически не должна зависет

Дата добавления: 2014-01-11