Реферат: Проблемы и тенденции развития технологий проектирования баз данных

Введение

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


1.Интегрированная база данных — констатация идеи

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

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

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

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


2.За идеей — классическая методология проектирования

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

сборсведений о ПрО (анализ потребностей и описание ПрО с использованием такназываемых «процессного» или UP, «usage perspective» подходаи «непроцессного» или ISP, «information structureperspective» подхода);

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

анализсобранных сведений о ПрО: классификация, формализация и интеграция структурныхэлементов описания ПрО, формализация как структурных, так и процедурныхограничений целостности элементов в будущей модели ПрО, определение динамикиэкземпляров объектов ПрО;

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

выборконкретной модели данных и СУБД для реализации БД;

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

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

разработкатехнологии и процедур начального создания и заполнения БД;

разработкатехнологии и процедур сопровождения БД;

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

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

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

тестированиеБД, ее развитие и улучшение (настройка) ее структуры.

Естьвсе основания называть методологию классической: для указанных методовразработаны полные, целостные методические системы, для большинства методовпредложены формализованные модели, эти модели — или, по крайней мере, ихитоговые выразительные возможности — нашли реальное применение в практикепроектирования. Один только перечень основных моделей данных и их авторовпроизводит внушительное впечатление, см. их обзор, например, в [Цикридзис85].

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

3.За методологией — мастерская инструментов проектирования БД

Проектированиекомплексной по предметной направленности, интегрированной и, обычно, большой поразмеру БД стало сложной задачей. Наличие целостной методологии проектированияпозволило позаботиться о «сапожнике-проектировщике» и начать шить емусапоги в виде систем автоматизации проектирования БД. Этому способствовалоналичие технологического опыта в организации и компьютерной поддержке системразработки программного обеспечения и, с другой стороны, использование активныхинтегрированных словарей-справочников данных (DD/D, Data Dictionary/Directory).Так возникли системы CASE (Computer Aided System Engineering) — системы дляструктурного проектирования БД и связанных с ними ИС, ориентированные на моделиданных, реализованные в различных СУБД. Наибольшую популярность получилиCASE-системы для реляционных СУБД с SQL-моделями данных, а DD/D переименовалсяв CASE-репозиторий проектируемой ИС.

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

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

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

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

4.Особо — о временных характеристиках и транзакциях

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

возможностисравнения временных параметров вариантов реализации разных вариантов схемы БД,на некоторой СУБД;

возможностисравнения параметров вариантов реализации одной схемы БД на разных СУБД;

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

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

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

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

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

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

5.Оценка достигнутого состояния

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

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

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

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

Вышешрифтом выделена цитата из [Цикритзис85]. С тех пор СУБД, методы проектированияБД и соответствующие инструменты значительно прибавили в возможностях. Ноостальной мир тоже не стоял на месте, существенно усложнились стоящие передразработчиками ИС и БД задачи. И надо признать: формулировки Цикритзиса иЛоховски не устарели.

6.Что и как из классических методов проектирования применяется в практикенастоящего времени

Применяютсяна практике:

СУБД,поддерживающие реляционную модель данных 1971 года с некоторыми расширениями(см., например, [Дадли96]);

Иерархическая«каскадная» схема структурного проектирования БД при подходе«сверху-вниз»;

CASE-системыдля структурного проектирования баз данных, ИС в целом или, к тому же,прикладных программ ИС. Наиболее часто используются: варианты ER-модели данных;табличная реляционная модель 1971 года, расширенная тем или иным дополнительнымнабором средств описаний ограничений целостности (ссылочная целостность,бизнес-правила); для анализа «процессного» источника сведений чащевсего предоставляются модели потоков данных или SADT, возможно, расширенныедополнительными связями по управлению (эти связи нельзя смешивать с выделеннымипотоками условий выполнения функций в нотации IDEF0);

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

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

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

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

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


7.Что теряется

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

полнаяпроцедура нормализации высоких степеней и минимизации набора отношений непроводится или проводится редко, если же экспертиза проверки на соответствиедаже 3НФ или БКНФ предусмотрена в CASE-средствах, эта возможность редкоиспользуется на практике ввиду ее громоздкости и высоких требований кквалификации проектировщика, использующего CASE;

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

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

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

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

высокиетребования к квалификации проектировщиков в области теоретических основклассического проектирования БД;

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

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

8.Ограничения классических методов

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

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

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

Наконец,наступило время, когда проектирование БД (и ИС в целом) по классическимправилам полноты и целостности часто стало практически бессмысленным. Весли П.Меллинг (Garthner Group) указал в [Меллинг95]: «К 1990 году почти всеаспекты „стандартной процедуры работы“ с ИТ (ИнформационнымиТехнологиями — прим. Е.З.) были оспорены, и вычислительные архитектурывырвались из-под контроля.… Стандарты программирования размывались, апонятие неизбыточных, непротиворечивых, высококачественных данных годилосьразве что для груды хлама».

9.Причины появления новых требований

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

Болеетого, новые возможности ИТ — вместе с рядом чисто экономических причин — привели к увеличению рыночных возможностей и требований потребителей, какследствие — к резкому усилению конкуренции в различных отраслях промышленностии услуг. Ответом послужило объявление императива бизнес-реинжиниринга: от BPRМ. Хаммера ([Hammer93]) до строительства киберкорпораций по Дж. Мартину([Мартин95]). В этих подходах требуется осуществление радикальных изменений ворганизации основной деятельности предприятий. В частности:

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

глобализациябизнеса: работа с клиентами и партнерами в любой точке мира, а также работа склиентом в режиме 24*365;

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

работана будущие потребности клиента, ускоренное продвижение новых технологий.

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

Также,как саму ИС нельзя рассматривать в отрыве от ее пользователей, и новоепроектирование должно рассматриваться как интеграция трех составных частей:требований бизнес- реинжиниринга, человеческого фактора и методов новых ИТ.Реальное объединение этих трех составных частей, каждая из которых приобрела в90-е годы качественно новое наполнение, создало начала того, что можно назватьНовым Системным Проектированием — Н.С.П.

10.Что нужно от баз данных для ответа на новые требования

Покажемновые требования к корпоративным БД на примере двух аспектов создания новыхкорпоративных ИС (из более чем двух десятков видов работ, составляющих основуН.С.П. — см. [Зиндер96]):

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

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

использованиеархитектуры и программных средств хранилища данных, средств ОперативнойАналитической Обработки Данных (OLAP), применение средств быстрой разработкиприложений (RAD) для создания «ИС руководителя» (EIS), средствподдержки принятия решений (DSS) на основе хранилища данных, OLAP и RAD/EIS;

применениесредств DSS на основе анализа БД прецедентов, а также методов логическоговывода, нейронных сетей и нейрокомпьютеров, и др.;

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

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

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

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

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

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

Некоторыеновые технические требования к базам данных можно получить из анализа в[Меллинг95].

11.Вошедшие в практику новые инструменты мастерской проектировщика

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

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

Возниклипрактически работающие стандарты de facto интероперабельной работы с данными, впервую очередь — стандарт ODBC.

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

Вошлив практику новые структуры и типы данных, новые операции над данными:неформатированные элементы, полнотекстовые БД и их обработка, ГИС-данные,мультимедийные БД, гипертекстовые распределенные БД, распределенная обработка иобработка, доставляемая вместе с объектом на вход ИС. На практике наблюдаютсяшаги реальной интеграции упомянутых структур и операций.

Меняетсяподход к выбору СУБД, в первую очередь — для проектирования корпоративных БД,эксплуатация и развитие которых планируется как минимум на несколько лет. Всеболее используются экономические основания и критерии для выбора СУБД (см.[Зиндер95а]).

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

12.К новым подходам в организации проектирования БД

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

Каскадныесхемы организации проектирования ПО для ИС достаточно давно сталипреобразовываться в циклические формы. Так, организация продолжающейсяразработки IBM corp. (см. [Фокс85]) предусматривала непрерывное контролируемоеразвитие программной системы в виде передачи в эксплуатацию ее новых версий.

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

Однако,такие циклические схемы сохраняют многие старые недостатки структурных методов.Для условий Н.С.П. важными недостатками являются:

трудоемкостьвнесения изменений в действующие компоненты;

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

Существуюти другие, например, громоздкость ведения проектной документации. Все этополностью относится и к проектированию БД.

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

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

13.От новых требований к типам и источникам информации — к новым архитектурнымпринципам БД

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

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

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

расширеннаятехнология Хранилища Данных, интегрирующая исторические форматированные данные,архивные текстовые документы, звуковые и видеоархивы, а также картографическиеданные, и включающая средства оперативной аналитической обработки данных,необходимые виды «дружественных» интерфейсов, например:гипертекстовый, ГеоИнформСистем и др.;

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

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

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

14.К новым подходам в методах проектирования БД

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

Обисключении избыточности в данных

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

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

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

Проблемаконсервации проблем

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

Предполагаемыеподходы:

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

проектированиеили реконструкция моделей компонентов ИС и БД, их интеграция в общем понятийномпространстве;

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

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

Компонентнаяоткрытость и смысловая интероперабельность

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

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

Разработкапонятийных моделей и СКК

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

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

Понятийныемодели и последующие проектные работы

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

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

разработкафункциональных моделей разных типов;

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

Технологическаяоткрытость

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

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

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

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

Проблемыобъемов, временных характеристик и физического проектирования

РаспространениеБД класса VLDB требует более активного использования методов проектированияэффективных физических схем данных. Невозможно строить такие БД рассчитывая напостоянную реорганизацию путем переписи в новые физические структуры. Это такдля операционных БД режима OLTP, тем более это так для терабайтных БД,ориентированных на OLAP. Легкость процедур выполнения реорганизаций указаннымметодом может становиться «ловушкой» для проектировщика, особенно — на первых этапах ввода БД в действие, когда ее перепись еще возможна из-занеполного объема.

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

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

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

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


Заключение

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

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

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


Литература

1.  Дадли К. Соответствие стандарту SQL.Бюллетень «Мир ORACLE», М., N. 1, 1996.

2.  Зиндер Е.З. Критерии выборасовременной СУБД как объекта инвестиций для развития предприятия. СУБД, N 1,1995.

3.   Зиндер Е.З. Революции и перспективы.Computerworld Россия, сентябрь 26, 1995.

4.  Зиндер Е.З. Новое системноепроектирование: информационные технологии и бизнес-реинжиниринг (вторая часть).СУБД, N 1, 1996.

5.  Калиниченко Л.А. СИНТЕЗ: языкопределения, проектирования и программирования интероперабельных среднеоднородных информационных ресурсов. М., ИПИ РАН, 1993.

6.  Мартин Дж. Превратите вашу компанию вкиберкорпорацию. Computerworld Россия, ноябрь 14, 1995.

7.  Меллинг В.П. Корпоративныеинформационные архитектуры: и все-таки они меняются. СУБД, N2, 1995.

8.  Фокс Дж. Программное обеспечение иего разработка. М., «МИР», 1985.

9.  Цикритзис Д., Лоховски Ф. Моделиданных. М., «Финансы и статистика», 1985.

10. Codd E.F.Extending the Database Relational Model to Capture More Meaning. ACM Trans.Database Syst., N 4, 1979.

11. Codd E.F., CoddS.B., and Salley C.T. Providing OLAP to User-Analyst: An IT Mandate. E.F.Codd& Associates, 1993.

12. Hammer M., ChampyJ. Reengineering the Corporation. A Manifesto for Business Revolutions.HarperBusiness, 1993.

13. Zinder E.Z.PRIMET — The PeRsonal Information MetaTechnologies: from marketing to programimplementation. //Общие проблемы информатики. III Международная конф.«Программное обеспечение ЭВМ» (ноябрь, Тверь, 1990) — Тверь: НПО ЦПС,1990.

еще рефераты
Еще работы по информатике, программированию