ИНФОРМАЦИОННО-СПРАВОЧНЫХ СИСТЕМ.

СТРУКТУРА И ОСНОВНЫЕ ЗАДАЧИ АВТОМАТИЗИРОВАННЫХ

ВВЕДЕНИЕ

Введение

С О Д Е Р Ж А Н И Е

Балашиха - 2013

Обсуждено на заседании ПМК № 1

По дисциплине

Л Е К Ц И Я № 24

Балашиха - 2013

По дисциплине

Л Е К Ц И Я № 24

«МЕТОДЫ ПРИНЯТИЯ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ»

Тема 8. «РАЗРАБОТКА И ПРИНЯТИЕ УПРАВЛЕНЧЕСКИХ

РЕШЕНИЙ НА ОСНОВЕ ИНФОРМАЦИОННО-КОММУНИКАЦИОННЫХ ТЕХНОЛОГИЙ»

Занятие 4. «Организация информационной поддержки

управленческой деятельности»

Время: 2 часа.

ВОЕННО-ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

_________________________________________________________________________________

Кафедра управления войсками

«МЕТОДЫ ПРИНЯТИЯ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ»

Тема 8. «РАЗРАБОТКА И ПРИНЯТИЕ УПРАВЛЕНЧЕСКИХ

РЕШЕНИЙ НА ОСНОВЕ ИНФОРМАЦИОННО-КОММУНИКАЦИОННЫХ ТЕХНОЛОГИЙ»

Занятие 4. «Организация информационной поддержки

управленческой деятельности»

Время: 2 часа

Протокол № ____

«_____» января 2013г.

Учебные вопросы (основная часть):

1. Структура и основные задачи автоматизированных информационно-справочных систем.

2. Технология проектирования базы данных.

3. Современные компьютерные сети.

Заключение

ЛИТЕРАТУРА:

1. Балдин К.В. Теоретические основы принятия управленческих решений. М.: Издательский дом, 2005, - 503 с.

2. Литвак Б.Г. Разработка управленческого решения. Учебник. – М.: Дело, 2006. – 440 с.

3. Горбовцов Г.Я. Методы принятия решений. М.: МЭСИ, 1999.

4. Ларичев О.И. Теория и методы принятия решений. 3 - е. изд., перераб. М.: Университетская книга, 2008.

5. Тимашков П.С. Математические методы принятия решений. М.: МЭСИ, 2003.

УЧЕБНО-МАТЕРИАЛЬНОЕ ОБЕСПЕЧЕНИЕ:

1. Наглядные пособия: электронная презентация –20 слайдов

2.Технические средства обучения: мультимедийная аудитория.

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

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

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

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

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

Если рассмотреть некоторый объект материального мира, информация о котором представляет интерес, и наблюдателя (в роли которого и выступают АИС), способного фиксировать эту информацию в определенной, понятной другим форме, то говорят, что в памяти («сознании») наблюдателя находятся данные, описывающие состояние объекта. Таким образом, данными, в дальнейшем, будем называть формализованную информацию, пригодную для последующей обработки, хранения и передачи средствами автоматизации профессиональной деятельности.

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

Информационное обеспечение (англ. information support) АИС - совокупность единой системы классификации и кодирования информации; унифицированных систем документации и используемых массивов информации. В дальнейшем нас будет интересовать именно последний аспект данного определения.

В этой связи в качестве главных задач создания информационного обеспечения АИС можно выделить:

• во-первых, определение состава и структуры данных, достаточно «хорошо» описывающих требуемую информацию

• во-вторых, обоснование способов хранения и переработки данных с использованием ЭВМ.

Прежде чем определить понятие «банк данных», необходимо остановиться на другом ключевом понятии - «предметная область».

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

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

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

Обеспечение информационных потребностей (запросов) пользователей имеет два аспекта:

• определение границ конкретной ПО и разработка описания соответствующей информационной модели;

• разработка БнД, ориентированного на эффективное обслуживание запросов различных категорий пользователей.

С точки зрения целевой направленности профессиональной деятельности принято выделять пять основных категорий пользователей:

• аналитики;

• системные программисты;

• прикладные программисты;

• администраторы;

• конечные пользователи.

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

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

• адекватность информации состоянию предметной области;

• быстродействие и производительность;

• простота и удобство использования;

• массовость использования;

• защита информации;

• возможность расширения круга решаемых задач.

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

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

• сокращение избыточности хранимых данных;

• устранение противоречивости хранимых данных;

• многоаспектное использование данных (при однократном вводе);

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

• обеспечение возможности стандартизации;

• обеспечение возможности санкционированного доступа к данным и др.

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

Структура типового БнД, удовлетворяющего предъявляемым требованиям, представлена на рисунке 1, где:

Рисунок 1. Основные компоненты БнД

• ВС - вычислительная система, включающая технические средства (ТС) и общее программное обеспечение (ОПО);

• БД - базы данных;

• СУБД - система управления БД;

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

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

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

Банк данных

ч вд

Словарь данных

ТС

В состав любой СУБД входят языки двух типов:

• язык описания данных (с его помощью описываются типы данных, их структура и связи);

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

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

• объектах, их свойствах и отношениях для данной ПО;

• данных, хранимых в БД (наименование; смысловое описание; структура; связи и т. п.);

• возможных значениях и форматах представления данных;

• источниках возникновения данных;

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

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

2. ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

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

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

Этап мифологического проектирования

♦___________

Выбор СУБД

Построение концептуальной модели данных (ЛП)

Построение физической модели данных (ФП)

Рисунок 2. Этапы проектирования БД

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

тиями.

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

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

• определение собственно сведений об объектах ПО;

• анализ возможных запросов к БД и требований по оперативности их выполнения.

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

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

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

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

Задача физического проектирования (ФП) - выбор способа хранения данных на физических носителях и методов доступа к ним с использованием воз-

можностей, предоставляемых СУБД.

Инфологическая модель «сущность - связь»

Мифологическая модель «сущность - связь» (Entity - Relationship model; ER-model) П. Чена (P. Chen) представляет собой описательную (неформальную) модель ПО, семантически определяющую в ней сущности и связи.

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

• сущность;

• атрибут;

• связь.

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

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

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

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

Наиболее распространены бинарные связи. Различают четыре их типа:

• один к одному (1:1);

• один ко многим (1:М);

• многие к одному (М:1);

• многие ко многим (M:N).

Графически типы сущностей, атрибуты и связи принято изображать прямоугольниками, овалами и ромбами соответственно (рис. 3) представлены примеры связей различных типов; на рис. 5.7 — фрагмент инфологической модели «Студенты» (без указания атрибутов).

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

при построении модели должны использоваться только три типа конструктивных элементов: сущность, атрибут, связь;

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

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

Так, информация о том, что некоторый студент входит в состав учебной группы (УГ), можно в модели представить:

• как связь «входит в состав» для сущностей «студент» и «УГ»;

• как атрибут «имеет в составе "студента" сущности "УГ"»;

• как сущность «состав УГ».

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

При моделировании ПО следует обращать внимание на существующий в ней документооборот. Именно документы, циркулирующие в ПО, должны являться основой для формулирования сущностей. Это связано с двумя обстоятельствами:

• во-первых, эти документы, как правило, достаточно полно отражают информацию, которую необходимо хранить в БД, причем в виде конкретных данных;

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

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

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

При определении связей между сущностями следует избегать связей типа M:N, т. к. они приводят к существенным затратам ресурсов ЭВМ. Устранение таких связей предусматривает введение других (дополнительных) элементов - сущностей и связей.

В заключение приведем типовую последовательность работ (действий) по построению инфологической модели:

• выделение в ПО сущностей;

• введение множества атрибутов для каждой сущности и выделение из них ключевых;

• исключение множества повторяющихся атрибутов (при необходимости);

• формирование связей между сущностями;

• исключение связей типа M:N (при необходимости);

• преобразование связей в однонаправленные (по возможности).

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

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

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

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

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

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

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

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

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

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

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

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

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

• запись;

• набор;

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

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

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

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

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

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

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

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

• найти л-е данное;

• найти первое (последнее) данное.

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

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

• ВУС = 200 100;

• ВОЗРАСТ > 20;

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

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

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

(УЧЕНОЕ ЗВАНИЕ = ДОЦЕНТ) ИЛИ (УЧЕНОЕ ЗВАНИЕ = ПРОФЕССОР) и т. п.

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

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

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

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

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

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

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

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

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

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

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

• сетевая;

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

• бинарная;

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

Рассмотрим основные особенности реляционных моделей как получивших наибольшее распространение (краткие сведения о семантических сетях помещены в подразд. 5.4.2, о других моделях — в [57]).

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

Данная модель была предложена Э. Ф. Коддом (Е. F. Codd) в начале 70-х годов и вместе с иерархической и сетевой моделями составляет множество так называемых великих моделей. В основе реляционной модели данных лежат не графические, а табличные методы и средства представления данных и манипулирования ими. В реляционной модели для отображения информации о предметной области используется таблица, называемая «отношением». Строка такой таблицы называется кортежем, столбец - атрибутом. Каждый атрибут может принимать некоторое подмножество значений из определенной области - домена (см. пример на рис. 5.8).

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

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