2.4.3. Классификация БнД по экономико-организационным признакам

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

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

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

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

2.5. Концепция централизованного управления

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

Преимущества централизованного управления данными

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

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

3. Возможность общего доступа к данным.

4. Возможность соблюдения стандартов.

5. Возможность введения ограничений для обеспечения безопасности.

6. Возможность обеспечения целостности (правильности и точности) данных.

7. Возможность сбалансировать противоречивые требования.

8. Обеспечение независимости данных.

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

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

Это является серьезным ограничением, так как:

1) для разных приложений требуются разные представления одних и тех же данных;

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

Таким образом, обеспечение независимости данных – основная цель систем баз данных. Независимость данных можно определить как иммунитет приложений к изменениям в структуре хранения данных и в методах доступа к данным. Далее будет рассмотрена архитектура систем баз данных, обеспечивающая основу для достижения этой цели. Предварительно необходимо рассмотреть три новых термина: хранимое поле, хранимая запись, хранимый файл (рис. 2.3) [9].

Хранимая база данных

Другие хранимые файлы

Хранимый файл PFILE с деталями

Номер Название Цвет Вес

детали детали детали детали

P1 Nut Red 12

Два экземпляра

хранимого типа Хранимые экземпляры полей

записи деталь

P2 Bolt Green 17

Номер Название Цвет Вес

детали детали детали детали

Рис. 2.3. Хранимые поля, записи и файлы

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

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

Хранимый файл – набор всех экземпляров хранимых записей одного типа.

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

• Представление числовых данных

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

• Представление символьных данных

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

• Единицы для числовых данных

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

• Кодирование данных

В некоторых ситуациях может понадобиться представлять данные кодированными значениями. Например, поле "цвет детали", которое представлено в приложении как символьная строка ("Красный", "Голубой", "Зеленый"), может храниться в виде десятичной цифры в соответствии с таблицей перекодировки: 1 = "Красный", 2 = "Голубой" и т.д.

• Материализация данных

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

• Структура хранимых записей

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

• Структура хранимых файлов

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

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