Характеристика современных автоматизированных информационных систем

системы. Метаданные в словаре–справочнике реляционной СУБД обычно организованы в виде набора таблиц.

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

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

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

Определения элементов данных в словаре осуществляются следующими видами описаний:

–описанием значений потоков и хранилищ, изображенных на DFD;

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

–описанием композиции групповых данных в хранилище;

–описанием деталей отношений между хранилищами.

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

–простые (элементарные) или групповые (комплексные) потоки;

–внутренние или внешние потоки;

–потоки данных или потоки управления; –непрерывные потоки.

Атрибуты потока данных включают:

–имена-синонимы потока данных в соответствии с узлами изменения имени;

–БНФ-определение в случае группового потока;

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

Концептуальное проектирование

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

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

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

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

Модель сущность-атрибут-связь (ER)

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

данных ER-модели получили широкое распространение в CASE системах, поддерживающих автоматизированное проектирование реляционных баз данных.

Базовыми понятиями ER-модели являются сущность, атрибут и связь.

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

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

Как и сущность, связь – это типовое понятие, все экземпляры обеих пар связываемых сущностей подчиняются правилам связывания. Может быть интерпретирована следующим образом:

Каждый СТУДЕНТ учится только в одной ГРУППЕ;

Любая ГРУППА состоит из одного или более СТУДЕНТОВ.

Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА;

Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ (“ЧЕЛОВЕКОВ”).

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

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

Связи “многие-со-многими”. Иногда бывает необходимо связывать сущности таким образом, что с обоих концов связи могут присутствовать несколько экземпляров сущности. Для этого вводится разновидность связи “многие-со- многими”.

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

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

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

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

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

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

Логическое проектирование

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

5.20 Иерархические структуры данных.

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

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

Пример типа дерева (схемы иерархической БД):

Здесь Отдел является предком для Начальник и Сотрудники, а Начальник и Сотрудники - потомки Отдел. Между типами записи поддерживаются связи.

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

В IMS использовалась оригинальная и нестандартная терминология: "сегмент" вместо "запись", а под "записью БД" понималось все дерево сегментов.

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

Найти указанное дерево БД ;

Перейти от одного дерева к другому;

Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику);

Перейти от одной записи к другой в порядке обхода иерархии;

Вставить новую запись в указанную позицию;

Удалить текущую запись.

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

В иерархических системах поддерживалась некоторая форма представлений БД на основе ограничения иерархии.

5,19 -2 На данном этапе выполняются следующие действия:

1. Удаление связей типа M:N.2. Удаление сложных связей.

3. Удаление рекурсивных связей.4. Удаление связей с атрибутами.

5. Удаление множественных атрибутов.6. Перепроверка связей типа 1:1.

7. Удаление избыточных связей.1. Удаление связей типа M:N. Если в концептуальной модели присутствуют связи типа M:N (“многие-ко-многим”), то их следует устранить путем определения некоторой промежуточной сущности.

2.Удаление сложных связей. Сложной называется связь, существующая между тремя и больше типами сущностей. Если в концептуальной модели присутствует сложная связь, ее следует устранить с помощью промежуточной сущности. Сложная связь заменяется необходимым количеством бинарных связей типа 1:М, устанавливаемых со вновь созданной сущностью.

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

4.Удаление связей с атрибутами. Если в концептуальной модели присутствуют связи, имеющие собственные атрибуты, они должны быть преобразованы путем создания новой сущности.

5.Удаление множественных атрибутов. Множественными называют атрибуты, которые могут иметь одновременно несколько значений для одного и

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

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

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

Физическое проектирование

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

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

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

Методология физического проектирования баз данных включает четыре основных этапа:

1.Разработка таблиц базы данных и установка необходимых ограничений целостности данных.

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

3.Проектирование системы защиты базы данных от несанкционированного доступа.

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

1.Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).

2.Данный тип записи P может быть типом записи предка в любом числе типов связи.

3.Данный тип записи P может быть типом записи потомка в любом числе типов связи.

4.Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.

5.Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.

6.Предок и потомок могут быть одного типа записи.

Простой пример сетевой схемы БД:

Примерный набор операций может быть следующим:

Найти конкретную запись в наборе однотипных записей (инженера Сидорова);

Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310);

Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);

Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);

Создать новую запись;

Уничтожить запись;

Модифицировать запись;

Включить в связь;

Исключить из связи;

Переставить в другую связь и т.д.

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

5.22 Физическое размещение данных.

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

направленных на достижение максимальной эффективности создаваемого проекта.

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

Методология физического проектирования баз данных включает четыре основных этапа:

1. Разработка таблиц базы данных и установка необходимых ограничений целостности данных.

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

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