Материал: 500_Goncharov_S._A._Informatsionnye_tekhnologii_v_mediaindustrii_Upravlenie_dannymi_

1.4. Классификация банков данных

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

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

По форме представления информации различают видео- и аудиосистемы,

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

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

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

Структурированные БД, в свою очередь, по типу используемой модели

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

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

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

По характеру организации хранения данных и обращения к ним

различают локальные (персональные), общие (интегрированные) и распределенные базы данных (рисунок 1.4).

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

11

База данных

Рисунок 1.4 – Классификация БнД по характеру хранения данных и обращения к ним

Классификация СУБД. Рассмотрим теперь ряд классификационных признаков, относящихся к СУБД. По языкам общения СУБД делятся на открытые, замкнутые и смешанные. Открытые системы — это системы, в которых для обращения к базам данных используются универсальные языки программирования. Замкнутые системы имеют собственные языки общения с пользователями БнД. Открытые системы в настоящее время используются редко.

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

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

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

12

Уровень 3 (подсхема) – концептуальная модель. Уровень 1 (схема) – даталогическая модель.

Уровень 2 (схема хранения) – внутренняя физическая модель.

Рисунок 1.5 – Классификация СУБД по числу уровней в архитектуре

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

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

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

1.5.Этапы проектирования баз данных

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

13

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

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

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

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

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

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

14

«поддерживает» схему, схему хранения и подсхему, то она является СУБД с трехуровневой архитектурой (см. классификацию БД).

Если СУБД поддерживает уровень подсхем, то перед проектировщиком встает задача их определения. Это тоже можно рассматривать как этап проектирования БД.

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

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

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

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

Взаимосвязь этапов проектирования БД. Инфологическая модель предметной области строится первой. Предварительная инфологическая модель строится еще на предпроектной стадии и затем уточняется на более поздних стадиях проектирования. Затем на ее основе строится даталогическая модель.

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

15