Содержание к диссертации
Введение
Глава 1. Анализ текущего состояния представления моделей данных 5
1.1. Назначение и критерии моделей 6
1.2. Уровни моделирования базы данных 9
1.3. Модели данных концептуального уровня 13
1.4. Реляционная модель данных 16
1.5. Эквивалентность реляционных схем 22
1.6. Методы автоматизации проектирования реляционных схем 25
1.7. Ограничения реляционной модели 28
1.8. Выводы и основные результаты главы. Критерии к объектно-реляционной модели представления данных 31
Глава 2. Логический уровень объектно-реляционных баз данных 35
2.1. Мифологический уровень 35
2.2. Проектирование инфологической схемы. ER-модель 41
2.3. Концептуальный уровень 45
2.4. Объектно-реляционная модель 59
2.5. Связь объектно-реляционной и реляционной модели 68
2.6. Выводы и основные результаты главы 74
Глава 3. Автоматизация проектирования логического уровня объектно- реляционной базы данных 76
3.1. Критерии построения моделей логического уровня 76
3.2. Базис для структуры объектно-реляционной модели 82
3.3. Формальная постановка задачи выбора конфигурации объектно-реляционной модели 87
3.4. Метод автоматизации проектирования объектно-реляционной модели базы данных 88
3.5. Пример выбора конфигурации модели 108
3.6. Оценка сложности метода 122
3.7. Выводы и основные результаты главы 124
Глава 4. Экспериментальная проверка предлагаемого метода 126
4.1. Описание концептуального уровня инструментальной среды 126
4.2. Проектирования реляционной и объектно-реляционной моделей в условиях изменяющейся предметной области 138
4.2.1. Предметная область «Химические установки» 139
4.2.2. Предметная область «Поставка деталей» 154
4.3. Выводы и основные результаты главы 164
Заключение . 165
Список использованной литературы
- Назначение и критерии моделей
- Мифологический уровень
- Критерии построения моделей логического уровня
- Описание концептуального уровня инструментальной среды
Введение к работе
Повсеместное использование баз данных в автоматизированных системах управления предприятиями (АСУП), выдвигает на первый план вопросы их эффективного использования.
Среди задач возникающих при проектировании и сопровождении баз данных (БД) всегда актуальны вопросы, связанные с автоматизацией методов и средств разработки моделей информационного представления бизнес-процессов в проектируемой системе, или, в общем виде - моделей данных описывающих предметную область.
В данной работе основное внимание уделено вопросам, связанным с автоматизацией отображением информации в концептуальных моделях данных БД, т.к. экономические показатели разрабатываемых и эксплуатируемых АСУП, и эффективность их функционирования, существенно зависят от организации информационного фонда, который в свою очередь регламентируется используемой в БД концептуальной моделью данных.
Доминирующие в настоящее время промышленные базы данных и системы управления базами данных, такие как: Oracle, MSSQL Server, Db2, Informix, SyBase, и т.д., базируются на реляционной модели представления данных.
Исследования проводимые в области теории и практики использования реляционных баз данных, зарубежными и отечественными учеными показали, что при проектировании и эксплуатации таких систем возникают противоречия, связанные с обеспечением логической независимости данных, в условиях изменяющейся предметной области, которые вызваны непосредственно ограничениями реляционной модели с отсутствием минимальной избыточности данных в таких моделях. Существующая потребность в использовании методов автоматизированного синтеза моделей БД в развивающихся АСУП, адекватно отражающих происходящие изменения в предметной области, и неэффективность использования для этих целей реляционного подхода представления данных, определяют актуальность темы диссертации.
Приведенные утверждения позволили сформулировать цель диссертационной работы: создание методов и средств автоматизации проектирования моделей баз данных, учитывающих семантические ограничения предметной области в условиях ее динамического развития и увеличивающих жизненный цикл информационного и программного обеспечения АСУП.
Назначение и критерии моделей
Основной целью создания и использования моделей данных в различных информационных системах (предназначенных для удовлетворения информационных потребностей предприятия), является снижение затрат на разработку и эксплуатацию АС, что достигается частичной автоматизацией процессов связанных с различными стадиями жизненного цикла системы (процессов проектирования, сопровождения и расширения АС).
База данных, как информационная модель предметной области АС, представляет собой описание состояния предметной области на формальном языке. Соотнесение представления объектов в базе данных их реальным прообразам достигается только посредством описания состояния предметной области на естественном языке. Введение формального языка приводит к необходимости однозначного перевода описания на одном языке (естественном или формальном) в описание на другом языке и к необходимости их эквивалентной интерпретации (рис. 1.1) .
Эквивалентная интерпретация достигается введением абстрактных состояний предметной области, определяемых формально [1, 2, 14, 23, 35, 57, 58] и служащих однозначной интерпретацией описания состояния, как на естественном, так и на формальном языке (соответствующие функции интерпретации на рис. 1.1 обозначены 1ЕА и 1ФА). Описания состояний на естественном и формальном языке эквивалентны, если одно из них является результатом перевода другого, и если их интерпретацией является одно и то же абстрактное состояние.
Очевидно, что формальное установление факта эквивалентности описаний состояния предметной области на различных языках, требует их абстрактной интерпретации в терминах некоторой эталонной модели. Со временем разработчики информационных систем пришли к выводу о необходимости введения понятия различных уровней абстракции [1, 3, 7, 12, 14, 29] для моделируемой ПО. На каждом из этих уровней абстракции локализуются свои собственные параметры (критерии) с минимальной зависимостью от параметров смежных уровней.
Задача проектирования модели сводится к последовательному эквивалентному отображению одного уровня абстракции в другом с учетом критериев к моделям каждого уровня. Практически во всех литературных источниках, связанных с базами данных, приводится подробный и обширный список критериев предъявляемых к различным моделям, но в качестве общепринятых выделяют: достоверность - соответствие способу определения и организации информации в данной ПО; отсутствие избыточности - исключение излишней информации; расширяемость - логическая независимость от данных. Способность развиваться и включать новые требования с минимальным воздействием на работу уже существующих моделей. Такие изменения концептуальной схемы, как добавление или удаление новых сущностей, атрибутов или связей, должны осуществляться без необходимости внесения изменений в уже существующие внешние схемы для других групп пользователей. Следует также отметить, что важный критерий производительности СУБД (точнее, тех средств, что использует АС для доступа к данным) скорость исполнения транзакции (выполнение запросов по модели), зачастую зависит непосредственно от организации модели, от ее внутренней структуры.
Внешний уровень является уровнем пользователей СУБД, так как он является уровнем восприятия каждого пользователя фрагмента предметной области, в рамках которой разрабатывается и функционирует информационная система. Типичным воплощением внешнего уровня является использование представлений (VIEW) в языке SQL [4, 6, 25, 39].
Концептуальный уровень является обобщением локальных представлений пользователей, то есть является общим глобальным описанием предметной области в терминах (концептах) конкретной СУБД и исполняет роль некоторого стандарта пользователей, согласуя их представление о предметной области в единое целое [1, 12].
Внутренний уровень наиболее близок к физическим структурам хранимой информации. Именно внутренний уровень учитывает методы доступа операционной системы для манипулирования данными на физическом уровне, что в некоторой степени снижает физическую независимость хранимых данных от технических средств хранения [12, 18, 59, 74].
На каждом уровне присутствует модель данных, которая специфицируется с помощью языка описания соответствующего уровня. Модель каждого уровня, представленную на языке описания, принято называть схемой. Так, например, концептуальная схема должна содержать; описание объектов и их атрибутов; описание и фиксацию связей между объектами; описание ограничений накладываемых на данные; описание средств и фиксацию ограничений структурной целостности модели.
Перевод моделей (описаний моделей) из одного уровня в другой осуществляется с помощью трансляции или интерпретации. Как отмечается многими авторами [13, 14, 17, 20, 21, 28 52], помимо указанных уровней моделирования данных, при проектировании любых систем, используется дополнительный уровень представления (отображения, абстракции, восприятия) информации, который носит название информационно-логического (инфологического), а его модель называют информационно-логической (Infological Model, 1LM).
Модель предметной области на инфологическом уровне указывает, что должна содержать и обрабатывать проектируемая система, отражая общие закономерности присущие информации, описывающей предметную область, не затрагивая вопросов как это будет реализовано в конкретной СУБД.
Мифологический уровень
Трехуровневая архитектура ANSI/SPARC [7], определяет принцип, согласно которому рекомендуется строить системы управления базами данных и преследует целью эффективное функционирование баз данных, опирающихся на принципы логической и физической независимости данных.
База данных представляет собой описание состояния предметной области на формальном языке. Причем на каждом из уровней архитектуры ANSI/SPARC присутствует модель данных, которая специфицируется с помощью языка описания соответствующего уровня. Поскольку на концептуальном уровне осуществляется формализованное описание предметной области в терминах конкретной СУБД, то одна и та же предметная область описывается по-разному средствами различных СУБД. На начальном этапе проектирования информационной базы разработчик еще может не знать, какая СУБД будет использоваться. Как отмечается многими авторами [13, 14, 17, 20, 21, 28 52], помимо указанных уровней моделирования данных, при проектировании любых систем, используется дополнительный уровень представления (отображения, абстракции, восприятия) информации, который носит название информационно-логического (иифологического), а его модель называют информационно-логической (Infological Model, ILM).
Отображение информационного пространства (исследуемого макрообъекта внешнего мира) в модели информационной базы показано на рис. 2.1. На первом этапе осуществляется отображение макрообъекта (рассматриваемого как множество составляющих его взаимосвязанных объектов) в ин-фологическую модель. Затем, после выбора СУБД, инфологическая модель отображается в концептуальную, а та, в свою очередь во внутреннюю и внешние модели информационной базы. При этом следует учитывать, что ILM является основой для математической (аксиоматической) концептуальной модели СУБД, и призвана устранить противоречия вызванные нечеткостью макрообъекта (многообразием элементов его составляющих и их временной соотнесенностью) и четкостью и дискретностью математического аппарата концептуального уровня.
В р мках СУБД Концептуальная модель Внутренняя модель / Внешняя модель - 1 Внешняя модель -п Рис. 2.1. Общая схема отображений ПО в рамках базы данных Модель предметной области на инфологическом уровне указывает, что должна содержать и обрабатывать проектируемая система, отражая общие закономерности присущие информации, описывающей предметную область, не затрагивая вопросов, как это будет реализовано в конкретной СУБД.
ILM - это средство абстракции, которое интерпретирует информационное содержание данных предметной области, частично представляя семантику данных предметной области, т.е. средство, передающее некоторые знания о реальном мире (предметной области).
Как и любая модель, TLM должна обеспечивать представление основных категорий восприятия внешнего мира - объектов (сущностей), свойств и связей объектов. Мифологический подход предполагает существование чистого множества таких понятий (категорий), которые должны быть интегрированы. Они являются чистыми в том смысле, что каждое понятие заключает в себе отличное от других значение, смысл которого доступен проектировщику. Основная задача, стоящая перед конструктором на инфологическом этапе проектирования, заключается в интеграции выделенных в предметной области понятий - элементов инфологической модели.
ILM предназначена для фиксации информационных потребностей проектируемой системы и является ее семантическим отображением, описывая проектируемую предметную область с использованием таких понятий, как объект, связь, свойство объекта, свойство связи [46]. Эти понятия различаются в проектируемой системе по именам (объектов, связей, свойств объектов, свойств связей), и формируются на основе следующих определений.
Определение 1. Объект (семантический объект) - понятие (или совокупность понятий) предметной области, содержание (смысл) которого сохраняется, если рассматривать его вне связи с другими понятиями. Иначе говоря, объект - это первичное понятие, содержание которого определяется за рамками системы и имеющее какое-либо применение в проектируемой модели. Термины экземпляр и объект взаимозаменяемы.
Определение 2. Свойство объекта - понятие (или совокупность понятий) предметной области, содержание которого раскрывается только в связи с данным объектом и не существует вне этой связи. На инфологическом уровне описания объекта важно, что свойство объекта не является объектом и существует только по отношению к объекту. Поэтому, указывая свойство, необходимо указывать и объект, обладающий этим свойством.
Определение 3. Связь - понятие (или совокупность понятий) предметной области, содержание которого проявляется только в отношении с двумя или более объектами.
Определение 4. Свойство связи - понятие (или совокупность понятий) предметной области, имеющая смысл только по отношению к данной связи.
В инфологической модели эти понятия соотносятся с понятием времени [20, 35]. Практика показывает, что любая предметная область, описываемая с помощью базы данных - это динамически развивающаяся система и жизнеспособность отдельных ее частей определяется инвариантностью моделей БД к изменениям окружающей предметной области. Однако, доминирующие в настоящее время реляционные базы данных, при проектировании моделей предметной области, имеют довольно серьезные ограничения, связанные с неадекватностью представления моделируемых объектов при динамическом изменении предметной области.
Включение времени в модель данных существенно расширяет ее возможности и, в частности, обеспечивает сохранение сведений о свойствах или связях которые более не являются достоверными. В [35] подробно рассмотрены вопросы, возникающие при использовании в различных моделях концепции времени.
В концептуальной модели предлагаемого объектно-реляционного подхода, временной аспект отражается с использованием фреймового способа представления данных и теории нечетких множеств, что позволяет с одной стороны формировать изменяющуюся структуру фрейма, и с другой стороны хранить такие состояния базы данных, которые, не являясь более действительными, представляют интерес для функционирования автоматизированной системы.
Набор объектов и связей, обладающих общими свойствами, объединяют под определениями класса объектов и класса связей соответственно.
Сложность осмысления понятий ILM заключается в том, что с течением времени они обладают свойством "перетекать" друг в друга, однако, пользуясь приведенной ниже методологией проектирования информационных моделей различного уровня можно структурировать и сгруппировать знания о предметной области и определить ее в приведенных инфологических концептах. Здесь следует подчеркнуть, что так или иначе, данные инфологиче-ские элементы найдут свое отражение в различных моделях концептуального уровня. Необходимо сделать важное замечание об ILM, как системе, а именно наличие интегративных [33] свойств ILM (т.е. таких свойств, которые присущи ILM в целом, и не свойственны ни одному из ее элементов в отдельности). Наличие интегративных свойств показывает, что ILM не сводится к простой совокупности элементов, и невозможности познать моделируемую ПО, разделив ее на части, и изучая каждую часть в отдельности.
Критерии построения моделей логического уровня
Основная цель создания моделей данных в различных АС заключается в снижение затрат на последующую разработку и эксплуатацию АС за счет частичной автоматизации процессов связанных с различными стадиями жизненного цикла автоматизированной системы (процессов проектирования, сопровождения и расширения АС). В процессе перевода из неформального описания на естественном языке в формализованную модель логического уровня, возможно получение моделей, удовлетворяющих исходным требованиям, но имеющих различные конфигурации. Поэтому и возникает задача выбора рациональной конфигурации модели.
Рациональность построенной модели данных можно оценить с помощью некоторых критериев, к которым относятся [8]: структурная достоверность — соответствие способу определения и организации информации в данной ПО; простота - удобство изучения модели, как профессионалам в области разработки информационных систем, так и обыкновенным пользователям; выразительность - способность представлять различия между данными, связи между данными и ограничения; отсутствие избыточности - исключение излишней информации; расширяемость - способность развиваться и включать новые требования с минимальным воздействием на работу уже существующих приложений; Чаще всего эти требования несовместимы, поэтому приходится идти на компромисс. Например, в погоне за наименьшей избыточностью модели данных можно пожертвовать ее простотой.
Цель оптимального синтаксического разложения заключается в подавлении избыточности хранимых данных. Вопросы избыточности с самого начала занимают важное место в проектировании баз данных и минимальная избыточность является важным критерием, обеспечивающим увеличение жизненного цикла базы данных, за счет снижения сложности эксплуатации. Все проекты, так или иначе, старались подавить избыточность данных, справедливо считая, что наличие ее может привести к многочисленным нежелательным явлениям при эксплуатации спроектированной базы данных.
Действительно, пусть (в терминах традиционной реляционной модели) в некотором отношении п раз (п 1) представлено значение а какого-либо ат 78 рибута А. Тогда возникают следующие моменты. Во-первых, вместо того, чтобы один раз сообщить о том, что А может иметь значение а, это сделано п раз и, следовательно, имеется n-кратный перерасход памяти. Во-вторых, при поиске информации из других атрибутов, связанной со значением а атрибута А, необходимо выполнить п обращений к отношению вместо того, чтобы один раз прочитать а и всю связанную с ним информацию; имеется, следовательно, n-кратное возрастание времени поиска информации. В-третьих, при корректировках базы данных при изменении (в реальности) значения а атрибута А, скажем, на значение b в базе данных соответствующие действия приходится выполнять п раз, резко увеличивая время корректировки, что само по себе плохо; гораздо хуже здесь, однако, то, что пропустив хоть один из имеющихся экземпляров значения а и скорректировав его, мы можем получить не соответствующую предметной области информацию, т.е., иными словами, база данных станет содержать ложную информацию.
В [17] показано, что существует такая структура FD, заданная на отношении R, что суммарный объем оптимального синтаксического разложения R больше объема неразложенного R. В параграфе 2.5 приведены примеры оптимального синтаксического разложения заданного исходного отношения, имеющие одинаковое количество отношений, но различающиеся по суммарному объему хранимых данных. То есть в общем случае критерий минимального количества отношений не влечет минимального объема синтезированных отношений и может приводить к дублированию хранимых объектов (или их связей).
Для объектно-реляционной модели критерий избыточности вводится на основании понятий хранимых экземпляров объектов и структурных связей между ними. Достижение минимальной избыточности в ОР модели ставит задачу минимизации дублирования заданных исходно объектов и связей между ними в полученном наборе фреймов.
Отметим, что в ОРМ структурные связи между доменом объекта и объектом (или другим объектом) всегда выполняются с использованием якорей (собственных и внесенных). В РМ имею место только связи (выполненные с помощью ключей) между непосредственно отношениями, связи же между доменами атрибутов и отношениями явно не заданы. Таким образом, в реляционной базе данных сами данные могут содержаться сколь угодно раз, а в объектно-реляционной для каждого занесения данных из соответствующего домена используются якоря.
Избыточность в формулах (3.6), (3.8) вычисляется для информационных элементов модели. Наличие якорей в объектно-реляционной модели позволяет сократить избыточность информационных элементов, и как следствие уменьшить размер самой базы данных. Однако, в этом случае, в ОРМ не 81 обходимо также минимизировать количество якорей в получаемой модели, которые являются «служебными» элементами: Х min. (3.9)
Вследствие использования якорей в объектно-реляционной модели, возникает вопрос корректного сравнения избыточности хранимых данных с реляционной моделью. В РМ все элементы являются информационными, данные связываются с помощью значений информационных элементов, и понятие, схожее с понятием якоря в ОРМ, отсутствует. В ОРМ якоря являются служебными элементами, и избыточность (в традиционном понимании реляционного подхода), вычисляемая по информационным элементам, ниже чем в РМ при отображении одинаковых предметных областей.
Описание концептуального уровня инструментальной среды
Центральная идея предлагаемого метода - отказ от теории нормализации как единственной теоретической основы проектирования моделей баз данных реляционного типа и использование теории фреймов (в совокупности с теорией нормализации) для этих целей.
Следствием такого решения является использование реляционного ключа только как добавочного средства (вспомогательного) для учета ограничений целостности объекта на котором он определен и кодирование каждого отдельного элемента (объектов и их связей) предметной области собственным идентификатором - (собственного) якоря. Значение этого идентификатора позволяет, совместно с именем класса объекта, отличить его от всех других объектов любого класса.
Основой этой идеи послужила убежденность в том, что в модели базы данных могут быть представлены объекты (обозначим это множество буквой О) произвольной природы, об элементах которых мы обладаем неполной информацией.
Однако если нам представляют некоторый объект, то мы однозначно можем сказать, принадлежит ли он множеству О или не принадлежит.
Кроме того, для любых двух элементов из множества О мы можем сказать, совпадают ли они между собой или нет. Так, примером такого множества могут служить сотрудники некоторого предприятия в данный момент времени. В множестве сотрудников не бывает двух одинаковых людей и если реляционный ключ был определен на атрибуте (свойстве) «фамилия», то со временем на предприятии могут появиться однофамильцы и реляционный ключ будет расширен отличительным признаком, позволяющим отличать один экземпляр от другого (например, добавлен атрибут «ИНН»). При этом собственный якорь останется неизменным, реляционный ключ изменяется.
Далее вводится конечный набор синтаксических (структурных) правил, с помощью которых из элементов множества О, можно построить правильные (допустимые) совокупности элементов. Эти структурные правила образуют второй элемент формальной системы. В качестве примера группировка сотрудников некоторого учреждения может определяться, например, распоряжением руководителем предприятия, в котором устанавливаются структурные подразделения (отделы, цеха, участки и т. д.). Правила уточняют принадлежность (к данному моменту времени) того или иного сотрудника к той или иной выделенной конструктором модели совокупности.
Следующим элементом формальной системы являются аксиомы (ограничения). Так, например, для множества сотрудников аксиомами можно считать директора и всех руководителей подразделений, каждый из которых не считается включенным в совокупность сотрудников, образующих сами подразделения.
Последним элементом формальной системы являются правила вывода, примером которого может служить язык QBE или SQL.
Подобная система может быть реализована в любом языке программирования или в СУБД, имеющей встроенные языки. Это было сделано (после теоретических исследований и выполнения большого объема практической работы по программированию), при участии автора в среде СУБД ORD (ORD - Object-Relational Dynamic Data-Frame Structures - объектно-реляционные динамические фреймовые структуры) [66].
Есть много способов сравнить различные системы. Рассматривая модели данных с одинаковыми выразительными возможностями можно учитывать: - занимаемое в памяти место; - скорость поиска; - гибкость структур данных; - устойчивость структурных связей; - возможности средств поддержки целостности и непротиворечивости данных.
Все эти моменты отдельно рассмотрены ранее в соответствующих разделах диссертации или руководств по системе ORD [66]. Здесь же указываются лишь некоторые преимущества предлагаемых моделей данных. Это следующее: 1. Расширение состава компонент реляционного ключа (РК) в пределах имеющихся свойств объекта не влечет за собой никаких изменений фреймовой модели. 2. Изменение значений компонент РК не требует никаких изменений содержимого связанных таблиц в модели и в случае ошибок ввода не приводит к нарушению связей модели.(Более того, пользователь приложений не имеет возможности редактировать реляционные ключи - якоря, так как это делается только самой системой.) 3. Поисковые операции по составным РК в моделях данных с многими связями выполняются значительно быстрее, чем в традиционных реляционных моделях. В разработанной системе имеется мощная встроенная поддержка целостности данных. Она основана на шестикомпонентной модели (фрейма) данных, которая используется для отображения всех возможных структурных связей объектов и ограничений этих связей. Известно, что в теории баз данных рассматриваются 4 типа структурных связей: 1 : 1, 1 : N, М : 1, и М : N. Второй и третий типы в большинстве случаев подобны, хотя между ними иногда возможно провести более тонкие различия.
Эти связи представляются в фрейме с помощью шести основных типов компонент, соответствующих различному использованию таблиц данных.
Это: корневая таблица (типа «S» или «О» ), внешняя таблица (типа «В», хотя это название1 не совсем точно отражает ее место в модели), внутренняя таблица (типа «V») и три типа таблиц, называемых классификаторами: простым, сложным и модельным (типов «К», «Q» и «Н», соответственно).
(Кроме того, все типы могут иметь определенные модификации и разновидности, что подробно описывается в руководствах по ORD.)
Любая модель данных (объекта) начинается с корневой (базовой) таблицы, тип которой далее для определенности принимается за «S». Все остальные таблицы подключаются к модели посредством занесения в их строки якорей, связанных с ними строк вышестоящей таблицы (связки «S» с «V» или «V» с «V»), или занесения якорей строк подключаемых таблиц в строки вышестоящей таблицы (классификаторные связки «К», «Q» или «Н» с «S», «V» или «Н»).
