Главная > Разное > Моделирование систем
<< Предыдущий параграф
Следующий параграф >>
<< Предыдущий параграф Следующий параграф >>
Макеты страниц

5.4. БАЗЫ ДАННЫХ МОДЕЛИРОВАНИЯ

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

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

Рассмотрим основные моменты связанные с разработкой распределенной базы данных моделирования (РБДМ).

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

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

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

Такой подход, безусловно, оправдан при проектировании БД в тех случаях, когда администратор БД владеет схемой соответствия множества данных в реляционной модели с множеством данных о реальном мире. В тоже время, интеграционные тенденции, характерные для современного этапа развития компьютеризированных технологий (в том числе и в моделировании систем), ставят на повестку дня проблему построения интегрированных распределенных баз данных (ИРБД), для которых обеспечение схемной однородности на основе РМД в силу целого ряда причин оказывается недостаточно. Это не означает требования революционных изменений принципов реляционного подхода при проектировании БД в условиях построения ИРБД. Это означает только то, что при определении и построении ИРБД реляционный подход должен применяться с учетом классической схемы проектирования баз данных [2, 52], согласно которой необходимо знать, каким образом был

выполнен полный цикл этапов моделирования заданной предметной области в виде реляционных схем интегрируемых БД. Очевидно, что расширение границ применения реляционного подхода, при этом, позволит проектировать новые БД уже с учетом возможности их будущей интеграции и ИРБД. Характерным примером реализации расширения реляционного подхода для разработки распределенных приложений на основе интегрированных реляционных баз данных стало создание методов и средств -технологий [15].

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

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

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

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

Рис. 5.6. Полная технологическая схема реализация БДМ (см. скан)

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

Методы и средства определения и манипулирования БД. В технлогии БД определены две основные группы механизмов определения и манипулирования БД.

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

составляла главное направление развития. Хорошо известна многолетняя деятельность рабочей группы CODASYL [2] по созданию развитого ЯОД. Однако вывести языки определения данных на уровень общих языков программирования не удалось по целому ряду причин [3].

Вторую группу составляют методы и средства манипулирования данными, реализующие информативное связывание данных в динамике, в процессе доступа в БД. На начальных этапах языки манипулирования данными (ЯМД) сводились к определению простого -интерфейса, однако на рубеже 80-х годов тенденция развития ЯМД практически перекрыла направление разработки ЯОД. Благодаря широкому применению реляционной модели языки манипулирования смогли пройти путь становления до уровня общих языков программирования. Наиболее известным представителем семейства ЯМД на сегодняшний день является язык SQL (Structured Query Language) [2], составляющий основу и являющийся сам международным стандартом ЯМД.

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

— собственно язык манипулирования как инструмент;

— процедуры связывания данных и управления извлечением информации из БД, реализованные средствами ЯМД.

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

1) модули связывания и манипулирования данными встраиваются в приложения путем программирования в профессиональных средах (MS Visual Studio, С+ + Builder, Dlphi);

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

3) модули связывания и манипулирования оформляются в виде системных динамических загружаемых библиотек DLL, формируя таким образом доступ в БД в виде системного Windows-ресурса.

Построение модулей связывания и манипулирования БД в виде разделяемых информационных ресурсов в среде SQL-серверов или в виде системных DLL-библиотек существенно

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

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

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

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

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

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

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

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

— эвристические знания в виде принятых правил, соглашений и обозначений, характерных для систем

— экспертные знания и экспертные оценки специалистов в области моделирования конкретных систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— выделение абстракций объектов и процессов (взаимодействия объектов) через определение их свойств;

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

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

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

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

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

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

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

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

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

— построение инфологических структур реализации концептуальной модели, в качестве структур могут использоваться любые структуры определения структурных абстракций [2, 16, 25]; для реляционного подхода выполнение таких операций определяет процедуры инфологического проектирования связей соответствия, т. е. прототипов межтабличных отношений.

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

статистического моделирования), сохраняя концептуальную однородность семейства подобных Б ДМ (например, единая система Обозначений для типовых математических схем — см. гл. 2). Инфологическая модель является основой определения источников, накопителей и получателей информации и определения информационных потоков. И если своеобразным аналогом элементов концептуального проектирования в существующих СЛ-технологиях является моделирование сущностей-связей, то аналогом инфологического проектирования в СASE-технологиях может рассматриваться моделирования процессов прикладных областей [2, 26, 30].

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

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

— выделение таблиц для реализации схем логических объектов;

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

— выделение внешних, первичных и потенциальных ключей таблиц;

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

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

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

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

Важнейшей процедурой на этапе даталогического проектирования считается нормализация реляционных схем [3, 19, 23]. Однако,

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

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

Традиционное администрирование баз данных включает множество операций по сопровождению БД и описано в литературе [16, 52]. К числу решаемых в процессе администрирования БД задач обычно относятся:

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

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

— обеспечение целостности, достоверности и многие другие функции администрирования.

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

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

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

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

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

— администрирование компьютерной реализации БДМ, на этом уровне администрирования требуются знания системного программиста и владение методами и средствами СУБД;

— администрирование физической целостности и защиты БДМ; набор задач на этом уровне администрирования традиционен.

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

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

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

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

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

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

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

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

На сегодняшний день сформировано несколько методологий, использующих ОП. В первую очередь, к ним относится методология объектно-ориентированного программирования (ООП), реализация которой привела к построению ряда систем ООП, таких, как Visual С++, С++Builder, Delphi. Успешность и высокая результативность разработки систем ООП в значительной степени объясняется тем, что классифицируемые объекты предметных областей систем программирования по своей природе носят искусственный характер, обладают конечным числом известных свойств и хорошо

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

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

Методология классифицирования предметной области. В основе механизмов выделения классов и объектов предметной области лежит применение выбранной классификационной схемы. К числу основных классификационных методологий относятся методология классической категоризации, методология концептуальной класте-риазации и теория прототипов [16, 35].

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

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

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

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

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

Отметим, что совокупность классифицированных абстракций предметной области «моделирование систем в общем случае состоит из абстракций двух типов:

— абстракции определения объектов данных предметной области, которые называются абстракциями данных;

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

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

Например, стандартное окно системы Windows является объектом соответствующих классов (кнопка, панель, окно редактирования и т. п.).

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

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

Интерфейс и реализация исполняются в среде разработки проектируемой системы, поэтому можно построить следующую логическую цепочку взаимосвязи понятий: интерфейс есть исполнение абстракции, а реализация есть исполнение интерфейса. Например, в системах ООП интерфейс и реализация исполняются на языках С++, Object Pascal и др. Для систем объектно-ориентированных БД смысл инкапсуляции, в первую очередь, связан с разделением модельных представлений абстракций данных и реализации объектов данных одного классификационного раздела в различном схемном исполнении. Логическая последовательность взаимосвязи понятий в этом случае следующая.

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

Иерархия реализует свойство объектной модели упорядочения и расположения по уровням выделенных абстракций предметной области. Основным свойством и преимуществом иерархической организации объектной модели является наследование свойств и других элементов определения объектов по схеме «родитель-потомок», при этом наследование касается только интерфейсных определений. О наследовании говорят, как об иерархии «обобщение-специализация», что в значительной степени напоминает определение родовидовых зависимостей. И если в системах объектно-ориентированного программирования иерархии классов отностиль-но просты и понятны (например, иерархии классов библиотеки MFC языка Visual С++, или библиотеки VCL системы Delphi), то для систем объектно-ориентированных баз данных иерархии классов оказываются многомерными.

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

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

Свойство модульности достаточно очевидно и должно быть

реализовано в любой программной разработке. Модульность реализует абстрагирование не на уровне классов объектов, а на уровне программных единиц разрабатываемой системы. В этом смысле модуль можно уподобить классу с описанием интерфейса и реализации, содержащему один объект в виде программной единицы (unit в языке Object Pascal). При разработке модулей следует придерживаться правила их типизации (модуль должен управлять однотипными объектами), что зачастую приводит к реализации модулей в виде объектов какого-то класса (например, диалоговые модули «открыть файл», «сохранить файл», «открыть графический файл» и другие реализованы в системе Delphi в виде объектных компонентов). Модульная организация системы является необходимым требованием, а сама суть модульности тесно переплетена с сутью других свойств объектной модели. Для объектно-ориентированных БД свойство модульности должно быть обеспечено на уровне манипулирования объектами БД (например, модульный принцип построения программ SQL-cepвepa на языке SQL).

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

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

Инфологическое проектирование баз данных. К числу основных задач этапа инфологического проектирования баз данных (рис. 5.8) относятся следующие три задачи:

1. Проектирование логических объектов.

2. Проектирование логических структур данных.

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

Рис. 5.7. Свойства объектной модели БДМ системы S (см. скан)

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

— реализацию концептуальной модели БД;

— выбор модели данных для реализации БД.

Модель и логические структуры данных. Существует множество типовых структур организации данных [2]. На сегодняшнем этапе развития компьютерных технологий типовые структуры важно рассматривать, с одной стороны, как основу построения абстракций при создании библиотек базовых классов объектно-ориентированных систем программирования, с другой стороны, как основу объектно-ориентированной ориентации моделирования баз данных.

Инфологическая модель БДМ. Инфологическая модель базы данных с ориентацией на ее реализацию в РМД представлена на рис. 5.9.

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

Рис. 5.8. Инфологическое проектирование БДМ (см. скан)

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

Рис. 5.9. Инфологическая модель БДМ с ориентацией на ее реализацию в РМД (см. скан)

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

Сформированная таким образом архитектура интеграционной методологии позволяет сформулировать и определить ключевые понятия и принципы построения объектов компьютерных технологий класса интегрированных распределенных баз данных (ИРБД) [41, 52, 54].

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

Рис. 5.10. Основные понятия и определения интеграционной методологии (см. скан)

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

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

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

Реляционная модель обеспечивает однородность представления распределенных данных. Механизм псевдонимов обеспечивает однородность среды манипулирования распределенными данными (например, система драйверов БД DAO использует приложение Microsoft Jet Database Engine для однородного манипулирования базами данных Microsoft Access, а также FoxPro и Excel). В совокупности, таким образом, реализуется однородная среда определения и манипулирования распределенными данными. Назовем представление такой среды схемным модельным уровнем интегрированного представления совокупности распределенных распределенных данных, учитывая общепринятое понимание реализации реляционных БД в виде реляционных схем.

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

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

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

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

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

<< Предыдущий параграф Следующий параграф >>
Оглавление