ИНФОМАЦИОННОЕ МОДЕЛИРОВАНИЕ ПРЕДМЕТНЫХ ОБЛАСТЕЙ ДЛЯ БАЗ ДАННЫХ

2.1. Отображение явлений реального мира
данными

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

При информационном моделировании рассматриваются:

· явления реального мира;

· информация об этих явлениях;

· представление этой информации посредством данных.

Информационное моделирование ПО определяют два фактора:

· идеология организации данных в БД;

· особенности выбранной СУБД.

На Рис. 0.1 это отображено соответствующими блоками: реальный мир, информационная сфера, датологическая сфера.

 

	Информа-ция		Данные
Реальный мир		Информацион-ная сфера		Датологиче-ская сфера

 

Рис. 0.1

Для представления информации о конкретной ПО необходимо:

· выделить в рассматриваемой ПО реального мира объекты для информационного отображения в БД;

· для каждого объекта выявить свойства, достаточные для его описания;

· определить виды взаимосвязей (или отношений) между объектами;

· установить совокупности данных о выделенных объектах, необходимые и достаточные для их представления в БД.

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

2.2. Инфологическое моделирование ПО

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

На этом этапе осуществляется:

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

· выявление объектов или явлений реального мира, информацию о которых требуется накапливать и обрабатывать;

· перечень учитываемых характеристик и их взаимосвязей;

При инфологическом моделировании основным составным элементом ПО является " сущность".

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

Примеры: товар, адрес, процессор, платежное поручение, счет-фактура и т.п.

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

Характеристика, описывающая какое-либо свойство сущности, которое можно сформулировать и записать, называется атрибутом.

Примеры: количество, цвет, цена, прибыль и т.п.

Для задания атрибута необходимо:

· присвоить атрибуту имя;

· сформулировать смысловое описание атрибута;

· указать роль атрибута, т.е. смысл его использования;

· задать множество допустимых значений атрибута.

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

Все информационные объекты делятся на два вида:

· материальные: вид товара, населенный пункт, станок и т.п.

· нематериальные: счет в банке, событие, адрес клиента и т.п.

По структуре объекты разделяются на:

· атомарные;

· составные.

Атомарными информационными объектами называются сущности, которые неразделимы на какие-либо более мелкие.

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

По взаимосвязям с другими объектами информационные объекты могут разделяться на локальные и реляционные.

Информационный объект, свойства которого не зависят от его отношений с другими объектами, называется локальным информационным объектом.

Информационный объект, свойства которого зависят от его отношений с другими объектами, называется реляционным информационным объектом.

Каждая связь (или отношение) между информационными объектами по числу входящих в него объектов характеризуется степенью n=1, 2,..., n. Соответственно связи сущностей могут быть бинарные (между двумя сущностями), тернарные (между тремя сущностями) и т.д. Чаще в информационных объектах связи бинарные.

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

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

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

2.3. Трехуровневое представление информационных объектов

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

· концептуальный;

· внешний;

· внутренний.

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

Внешнее представление информационного объекта (или пользовательская модель ПО) - это адаптированное к планируемому комплексу задач конкретного пользователя концептуальное представление информационного объекта.

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

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

· декомпозировать сложный процесс отображения ПО в БД на несколько более простых;

· обеспечить логическую и физическую независимость данных;

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

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

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

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

 

2.4. Структурные элементы для моделирования данных

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

Полем называется наименьшее поименованное (или элементарное) данное, к которому в БД можно непосредственно адресоваться. С помощью поля выполняется построение всех остальных структур данных. Для указания поля используется также и термин " атрибут ".

Поле, как и атрибут, может быть идентифицирующим полем, или идентификатором. 

По типам данных возможны поля:

· числового типа (целый или вещественный);

· нечислового типа (символьный или логический).

В БД с позиций моделирования рассматривают:

· тип поля (или тип данного);

· экземпляр (или значение) поля, т.е. само данное.

Пример.

Тип поля: ФИО;

значение поля: Иванов. 

 

Записью называется поименованная совокупность полей. Аналитическое выражение для записи можно представить в виде:

 

 (2.1)                                   Zj = U Pji,    i = 1, 2, …, Nj,

                                  i

 

где Zj – j – я запись;

Pji - i – е поле j – й записи;

Nj – количество полей в j –й записи.

Для записей, как и для поля, рассматривают тип записи и экземпляр записи.

Пример.

Тип записи: Служащий банка (ФИО, Дата Рождения, Образование, Должность)

с типами полей: ФИО, Дата Рождения, Образование, Должность.

Экземпляр записи для служащего банка:

Котов В.В., 17.04.75, Высшее, Инженер

 

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

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

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

 

(2.2)                        DB = {U Zj, j = 1, 2, …, M; U Bk, k = 1, 2, …, K},                   

                               j                            k

 

где Zj – j – я запись;

Bk – k –я связь в базе данных.

БД должна удовлетворять следующим требованиям:

· поддержание логической структуры данных;

· быстрота обработки запросов;

· минимизация ресурсов памяти для размещения данных;

· минимальная избыточность данных;

· целостность данных;

· логическая независимость;

· физическая независимость;

· безопасность и секретность данных;

· единство управления при вводе, модификации, по-

· иске данных;

· эффективность пользовательского интерфейса для работы с БД.

2.5. Ключи БД

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

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

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

Пример простого ключа приведён на Рис. 0.2. От ключа исходят связи к остальным полям.

 

 

 

Рис. 0.2

 

Пример сцепленного ключа показан на

           

 

Рис. 0.3. Здесь первичный ключ состоит из двух полей: №Рейса + Дата. Такой ключ обрабатывается как одно поле.

 

 

 

 

                           вылета

 

 

                                                                             

 

Рис. 0.3

 

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

2.6. Интеграция полей БД в отношения

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

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

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

При объединении полей в записи целесообразно выполнять следующие правила:

· записи и поля должны быть поименованы; повтор их имен не допускается. Запись может иметь имя одного из включенных полей

· в записях выделяются ключи. Первичный ключ каждой записи подчеркивается. Связи вторичных ключей отображаются двойными стрелками;

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

2.7. Требования интеграции полей в отношения

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

1) каждая запись должна иметь простую структуру, т.е. иметь простой ключ, и лишь некоторые записи- сложную структуру;

2) лаконичность ключей, выбранных для отношений;

3) обеспечение свободы выполнения операций включения, удаления и модификации данных в БД;

4) минимальность реструктурирования отношений при введении новых типов данных.

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

Пример.

Рассмотрим в реляционной БД отношение типа:

(2.6) Поставка(Индекс, ИмяПоставщика, Адрес, Товар, Цена)      

Из структуры видно, что в каждом экземпляре отношения типа (2.6) будет повторяться адрес поставщика. Это приводит к следующим аномалиям:

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

· аномалия удаления. При прекращении поставок, например, по окончании отчетного периода, от одного из поставщиков и адекватном удалении всех соответствующих кортежей с прекращенными поставками произойдет потеря реквизитов поставщика. Это означает, что будет потеряны адрес, имя поставщика и т.п., хотя, например, заключенный с ним договор еще в силе, и просто очередная поставка будет позже. В такой ситуации система не ответит на запрос типа: " С какими поставщиками заключены договоры? "

· 3) аномалия включения. При заключении договора с новым поставщиком, от которого еще нет поставок, нельзя включить в БД его реквизиты: Имя Поставщика и Адрес, так как нельзя сформировать полный кортеж из-за отсутствия данных по поставке, и в первую очередь ключа кортежа. Введение же, например, пробелов может вызвать дальнейшие недоразумения и не всегда возможно. Так, если указанные атрибуты входят в состав ключа, то организовать поиск кортежа с неопределённым значением ключа невозможно.

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

2.8. Обобщенная структура модели данных в БНД

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

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

Индивидуальные представления отдельных пользователей П1, П2..., ПN об информационных объектах ПО отображают пользовательские модели (или внешние модели) ПО: ПМПО1, ПМПО2,..., ПМПОN.

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

· информационную модель БД (ИМ БД);

· БД;

· прикладные программы (ПП) пользователей БД.

 ИМ БД, в свою очередь, включает в себя:

· датологическую модель БД (ДЛМ БД) (или схему БД);

· физическую модель БД (ФМ БД) (или схему хранения БД), полное название которой - модель данных физического уровня.

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

ФМ БД, во-первых, является моделью БД, а во-вторых, - косвенно моделирует ПО. ФМ БД используется для привязки ДЛМ БД к среде физического хранения данных, т.е. к техническим средствам. ФМ БД

строится с учетом возможностей СУБД, ОС и определяет:

· используемые ЗУ;

· способ размещения элементов данных в ЗУ;

· способы физической реализации логических отношений между элементами данных.

2.9. ER-модель БД

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

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

ER-модель является неформальной моделью и используется на этапе инфологического проектирования. В этой модели понятие " сущность" фактически является синонимом понятия " запись". Для построения ER-модели применяются три конструктивных элемента:  

 

 

ПРЕДМЕТНАЯ ОБЛАСТЬ

ИЛМ

ОИПП

ГМ

ПО

Администратор БД

П1

ПМПО П1

ПП П1

ДЛМ БД

П2

ПМПО П2

ПП П2

ФМ БД

ИМ БД

ПN

ПМПО ПN

ПП ПN

{Пользова-тели}

{Пользова-тельские модели}

{Прикладные программы (ПП) пользователей}

{База Данных}

Внешнее представление ПО

Информационная модель ПО

СУБД

 

Рис. 0.4

· сущность;

· атрибут;

· связь. 

ER-модель обеспечивает:

· семантическое описание ПО;

· исходную информацию для обоснования выбора видов моделей и структур данных в автоматизированной информационной системе.

Для ER-модели используются понятия:  

· тип сущности;

· экземпляр сущности.

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

 

Пример

Тип сущности Специалисты может описываться атрибутами:

Табельный номер, ФИО, Специальность.

Здесь поле типа Табельный номер будем считать идентификатором. Запись для этой сущности можно представить в виде:

Специалисты(ТабельныйНомер, Специальность, ФИО).

 

Примечание.

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

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

 

Пример.

Пусть тип сущности Отделы описывается атрибутами:

НазваниеОтдела, Адрес.

Поле типа НазваниеОтдела можно принять в качестве идентификатора сущности. Моделирующий данный тип сущности соответствующий тип записи можно представить в виде:

Отделы(НазваниеОтдела, Адрес).

 

Экземпляр сущности - это конкретный информационный объект из набора, моделируемый экземпляром записи, в котором значение атрибута моделируется значением поля

Пример.

Экземпляры сущности типа Специалисты:

2015, Котов А.И., Техник;

0123, Алексеев Б.Р., Менеджер;

1157, Киров Б.В., Программист.

 

Пример.

Экземпляры сущности типа Отделы:

САПР, Корпус 1;

АСУТП, Корпус 3.

 

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

Пример.

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

РаботаетВ(ТабельныйНомер, НазваниеОтдела),

Экземпляр связи типа РаботаетВ определяется конкретными экземплярами соответствующих рассматриваемых типов сущностей.

Пример.

Для приведенных выше экземпляров записей можно записать экземпляр связи в виде: 2015, АСУ.

Здесь идентификатор 2015 определяет запись для техника Котова А.И., а идентификатор АСУ определяет отдел, в котором работает этот техник.

2.10. Формирование связей сущностей

Рассмотрим сущность типа Служащий, запись которой имеет вид:

(2.3)            Служащий (№Таб, ФИО, ГодРождения, Образование)  

и сущность типа " Отдел":

(2.4)            Отдел (№Отдела, Корпус, НачальникОтдела)

с идентифицирующими атрибутами соответственно №Таб и №Отдела.

На основе записей (2.3) и (2.4) для этих сущностей нельзя ответить, например, на запрос о том, какие конкретно сотрудники работают в том или ином отделе, т.к. между сущностями нет связей (Рис. 0.5).

 

Сущность (2.3)	Связь -?	Сущность (2.4)

Рис. 0.5

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

Для косвенного моделирования связи сущностей применяются два способа:

· введение дополнительной сущности;

· добавление в сущность общих атрибутов.

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: