<<
>>

2.1.3. Концептуальные модели данных

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

По существу модель данных — это совокупность трех составляющих [15, 44]:

♦ типов (структур) данных;

♦ операций над данными;

♦ ограничений целостности.

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

Типы структур данных

Среди широкого множества определений, обозначающих типы структур данных, наиболее распространена термино­логия КОДАСИЛ (Conference of DAta SYstems Language) — международной ассоциации по языкам систем обработки дан­ных, созданной в 1959 г.

В соответствии с этой терминологией используют пять типовых структур (в порядке усложнения):

♦ элемент данных;

♦ агрегат данных;

♦ запись;

♦ набор;

♦ база данных.

Дадим краткие определения этих структур [15, 44, 45].

Элемент данных — наименьшая поименованная единица данных, к которой СУБД может адресоваться непосредственно и с помощью которой выполняется построение всех осталь­ных структур данных.

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

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

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

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

Отметим, что структуры БД строятся на основании сле­дующих основных композиционных правил [15, 44]:

♦ БД может содержать любое количество типов записей и типов наборов;

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

♦ тип записи может быть владельцем и одновременно чле­ном нескольких типов наборов.

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

Рассмотренные типы структур данных могут быть пред­ставлены в различной форме — графовой; табличной; в виде исходного текста языка описания данных конкретной СУБД.

Операции над данными

Операции, реализуемые СУБД, включают селекцию (по­иск) данных; действия над данными.

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

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

♦ найти следующее данное (запись);

♦ найти предыдущее данное;

♦ найти п-ое данное;

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

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

♦ ВУС = 200100;

♦ ВОЗРАСТ > 20;

♦ ДАТА < 19.04.2002 и т. п.

Булево условие отбора формируется путем объединения простых условий с применением логических операций, на­пример:

♦ (ДАТА_РОЖДЕНИЯ < 28.12.1963) И (СТАЖ> 10);

♦ (УЧЕНОЕ_ЗВАНИЕ=ДОЦЕНТ:) ИЛИ (УЧЕНОЕ

ЗВАНИЕ=ПРОФЕССОР) и т. п.

Если модель данных, поддерживаемая некоторой СУБД, позволяет выполнить селекцию данных по связям, то можно найти данные, связанные с текущим значением какого-либо данного [46]. Например, если в модели данных реализована двунаправленная связь "учится" между сущностями "студент" и "учебная группа", можно выявить учебные группы, в ко­торых учатся юноши (если в составе описания студента вхо­дит атрибут "пол").

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

Ограничения целостности

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

Различают внутренние и явные ограничения.

Ограничения, обусловленные возможностями конкрет­ной СУБД, называют внутренними ограничениями целост­ности. Эти ограничения касаются типов хранимых данных (например, "текстовый элемент данных может состоять не более чем из 256 символов" или "запись может содержать не более 100 полей") и допустимых типов связей (например, СУБД может поддерживать только так называемые функци­ональные связи, т. е. связи типа 1:1, 1:М или М:1). Большин­ство существующих СУБД поддерживают прежде всего имен­но внутренние ограничения целостности [46], нарушения ко­торых приводят к некорректности данных и достаточно лег­ко контролируются.

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

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

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

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

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

♦ иерархическая;

♦ сетевая;

♦ реляционная;

♦ бинарная;

♦ семантическая сеть.

Рассмотрим основные особенности перечисленных моде­лей.

Иерархическая модель данных

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

На рис. 2.1.9 показан фрагмент объектной записи в иерар­хической модели данных. Часто используется также "упоря­доченное дерево", в котором значим относительный порядок поддеревьев.

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

Характерные примеры реализации иерархических струк­тур — язык Кобол и СУБД семейства IMS (создана в рамках проекта высадки на Луну — "Аполлон") и System 2000 (S2K).

Рис. 2.1.9. Фрагмент иерархической модели данных




Сетевая модель данных

В системе баз данных, предложенных COD ASYL, за ос­нову была взята сетевая структура. Существенное влияние на разработку этой модели оказали ранние сетевые систе­мы — IDS и Ассоциативный ПЛ/1. Необходимость в процессе получения одного отчета обрабатывать несколько файлов обус­ловила целесообразность установления перекрестных ссылок между файлами, что в конце концов и привело к сетевым структурам [54].

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

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

Кафедра "Менеджмент" Кафедра "Экономика"



Учебная дисциплина "Управление персоналом"

Учебная дисциплина "Менеджмент"

Учебная дисциплина "Экономика"



Студент факультета экономики

Студент факультета менеджмента

Студент юридического факультета



Рис. 2.1.10. Фрагмент сетевой модели данных

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

222

с ростом объема информации сетевая структура становится весьма сложной для описания и анализа.

Известно [62], что применение на практике иерархи­ческих и сетевых моделей данных в некоторых случаях тре­бует разработки и сопровождения значительного объема кода приложения, что иногда может стать для информационной системы непосильным бременем.

Реляционная модель данных

В основе реляционной модели данных (см. п. 2.1.4) лежат не графические, а табличные методы и средства представ­ления данных и манипулирования ими (рис. 2.1.11). В реляци­онной модели для отображения информации о предметной области используется таблица, называемая "отношением". Строка такой таблицы называется кортежем, столбец — ат­рибутом. Каждый атрибут может принимать некоторое под­множество значений из определенной области — домена [42].



Первичный

ключ

Вуз

МГУ им. М. В. Ло­моносова

Место рас­положения

г. Москва

Количество обучаемых (студентов)

26170

Поле базы данных (атрибут сущности)



Государ­ственный технический ^нивераугет

Домен (множество) возможных значений характери­стики объекта)

12 150

г. Санкт- Петербург

Кортеж (вектор размерности к, включающий по одному из возможных значений к доменов)



Рис. 2.1.11. Фрагмент реляционной модели данных

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

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

Подавляющее большинство СУБД, ориентированных на персональные ЭВМ, являются системами, построенными на основе реляционной модели данных — реляционными СУБД.

Бинарная модель данных

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

Рис. 2.1.12. Пример бинарного отношения


Бинарная модель не получила особо широкого распрост­ранения, но в ряде случаев находит практическое примене­ние.

Так, в области искусственного интеллекта уже давно ведутся исследования с целью представления информации в виде бинарных отношений. Рассмотрим триаду (тройку) "объект—атрибут—значение" (более подробно об этом будет сказано в подразд. 4.2). Триада "Кузнецов—возраст—20" оз­начает, что возраст некоего Кузнецова равен 20 годам. Эта же информация может быть выражена, например, бинар­ным отношением ВОЗРАСТ. Понятие бинарного отношения положено в основу таких моделей данных, как, например, Data Semantics (автор Абриал) и DIAM II (автор Сенко).

Бинарные модели данных обладают возможностью пред­ставления связки любой сложности (и это их несомненное преимущество), но вместе с тем их ориентация на пользова­теля недостаточна [53].

Семантическая сеть

Семантические сети как модели данных были предложе­ны исследователями, работавшими над различными пробле­мами искусственного интеллекта (см. разд. 4). Так же, как в сетевой и бинарной моделях, базовые структуры семанти­ческой сети могут быть представлены графом, множество вершин и дуг которого образует сеть. Однако семантические сети предназначены для представления и систематизации знаний самого общего характера [53].

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

Семантические сети являются богатыми источниками идей моделирования данных, чрезвычайно полезных в плане ре­шения проблемы представления сложных ситуаций. Они мо­гут быть использованы независимо или совместно с идеями, положенными в основу других моделей данных. Их интерес­ной особенностью является то, что расстояние, измеренное на сети (семантическое расстояние или метрика), играет важ­ную роль, определяя близость взаимосвязанных понятий. При этом предусмотрена возможность в явной форме подчеркнуть, что семантическое расстояние велико. Как показано на рис. 2.1.13, СПЕЦИАЛЬНОСТЬ соотносится с личностью ПРЕ-

ПОДАВАТЕЛЬ, и в то же время ПРЕПОДАВАТЕЛЮ при­сущ РОСТ. Взаимосвязь личности со специальностью очевид­на, однако из этого не обязательно следует взаимосвязь СПЕ­ЦИАЛЬНОСТИ и РОСТА.

Следует сказать, что моделям данных типа семантичес­кой сети при всем присущем им богатстве возможностей при моделировании сложных ситуаций присуща усложненность и некоторая неэкономичность в концептуальном плане [53].

ПРЕПОДАВАТЕЛЬ

Рис. 2.1.13. Соотношение понятий в семантической сети

нерелевантно

СПЕЦИАЛЬНОСТЬ
> РОСТ



<< | >>
Источник: Балдин К. В., Уткин В. Б.. Информационные системы в экономике: Учебник. — 5-е изд. — М.: Издательско-торго- вая корпорация «Дашков и К0», — 395 с.. 2008 {original}

Еще по теме 2.1.3. Концептуальные модели данных:

  1. 5.5.1 Концептуальная модель данных
  2. Этап 2. Разработка концептуальной модели объекта
  3. 7.1. Концептуальная модель управления маркетингом малого бизнеса
  4. 2.1.4. Реляционная модель данных
  5. 2.1. Типы данных и регрессионная модель
  6. 5.2.1. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗ ДАННЫХ
  7. 5.2.2. ОБЪЕКТНАЯ МОДЕЛЬ БАЗ ДАННЫХ
  8. Связи между моделью данных и административными бизнес-процессами
  9. 4.7.1. МОДЕЛИ ОТОБРАЖЕНИЯ ДАННЫХ
  10. 4.4 Результативность и эффективность файлов данных (картотек, массивов данных)
  11. 3.1 . КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ
  12. 13.2.1. Концептуальное моделирование АИС
  13. Концептуальная матрица управления персоналом
  14. Сущность и концептуальные основы практического аудита
  15. 24. КОНЦЕПТУАЛЬНЫЕ ОСНОВЫ ПЕДАГОГИКИ