Никитина Т.П. Базы данных и знаний. Учебное пособие
Подождите немного. Документ загружается.
11
4. АВТОМАТИЗИРОВАННЫЕ БАНКИ ДАННЫХ
Автоматизированный банк данных – это система информационных
математических, программных, организационных и технических средств,
предназначенных для централизованного накопления и коллективного
многоаспектного использования данных.
Автоматизированный банк данных включает следующие основные
компоненты:
1) база данных;
2) система управления базой данных (СУБД);
3) администратор баз данных;
4) словарь данных;
5) вычислительная система;
6) обслуживающий персонал.
4.1. Архитектура банка данных
Каждый банк данных имеет свою предметную область (бухгалтерия, кадры,
склад и т.п.). Персонал, работающий в этой ПО, выступает в роли постоянных
пользователей банка данных. Каждый постоянный пользователь использует
определенные данные, содержащиеся, как правило, в первичных документах, то есть
каждый постоянный пользователь имеет некоторое субъективное представление об
обрабатываемых данных. Объединение этих представлений образует уровень -
внешняя модель. Внешняя модель отражает информационное содержание БД и
обеспечивает независимость прикладных программ от данных, обрабатываемых ими.
Кроме постоянных пользователей банка данных всегда выделяется некоторая
группа людей – разовых пользователей, которые, может быть, достаточно редко, но
вынуждены обращаться к банку данных. Для обеспечения потребностей и удобства
работы каждого пользователя вводится еще один уровень логического представления
данных: концептуальная модель. На этом уровне обобщаются и синхронизируются
все внешние представления.
Обычно при проектировании СУБД не разрабатывают программы
манипулирования данными на физическом уровне, а используются программы
методов доступа операционной системы, поэтому вводится модель представления
хранимых данных – уровень - внутренняя модель.
Таким образом, архитектура банка данных может быть представлена в виде
трех уровневой модели:
Рис. 4.1. Трехуровневая архитектура автоматизированного банка данных
Рассматриваемый трехуровневый подход к построению банков данных
получил наибольшее распространение.
При таком подходе на внешнем уровне реализуется модель ПО в виде,
требуемом для отдельных пользователей.
12
На концептуальном уровне поддерживается модель ПО для всех предложений.
Кроме названных трех уровней абстрагирования в банке данных может быть выделен
еще один. Модель этого уровня должна выражать информацию о ПО в виде,
независимом от конкретной используемой СУБД. С этим уровнем представления
работает администратор базы данных и пользователи системы. Модель этого уровня
должна опираться на их знания и использование естественного языка. Модель этого
уровня называется информационной моделью ПО.
4.2. Этапы проектирования банка данных
Проектирование банка данных представляет собой сложный процесс
реализации моделей основных уровней абстрагирования (информационной, внешней,
концептуальной, внутренней) и возможность отображения объектов одной модели
объектами другой.
Этапы проектирования автоматизированного банка данных представлены на
рис.4.2.
Рис.4.2. Этапы проектирования автоматизированного банка данных
В банках данных различают два аспекта и соответственно два этапа
проектирования:
1. инфологический;
2. датологический.
13
На этапе инфологического проектирования должны быть решены вопросы:
• о каких объектах или явлениях реального мира требуется накапливать и
обрабатывать информацию (ПО);
• какие основные характеристики и взаимосвязи будут учитываться
(ограничения на ПО);
• уточнения вводимых понятий об объектах и явлениях, их характеристиках и
взаимосвязях (словарь терминов и понятий).
Датологический аспект употребляется при рассмотрении вопросов:
• модели и методы представления и преобразования данных;
• формулирование правила смысловой интерпретации данных.
5. МОДЕЛЬ ПО
5.1. Модель «Сущность – связь»
Информационная модель ПО строится на этапе инфологического
проектирования. Существует несколько подходов к построению модели ПО.
Наиболее часто применяется для этих целей модель «Сущность – связь». Основными
компонентами модели являются: сущность, атрибут, связь. Информация о проекте
ПО представляется в виде диаграммы и спецификации. Модель «Сущность – связь»
относится к группе статических моделей (компонент "время" отсутствует).
Сущность – это абстракция реально существующего объекта. В качестве
сущностей в моделях предметной области рассматриваются материальные объекты
(предприятие, книга и т.д.) и результаты интеллектуального труда (патент, реферат и
т.д.).
Атрибут – это поименованная характеристика сущности, которая принимает
значения из некоторого множества значений (домена). Чтобы задать атрибут,
необходимо: присвоить ему имя; привести смысловое описание атрибута; определить
множество его допустимых значений. Назначение атрибута - описывать свойства
сущности. Один из атрибутов должен иметь уникальное значение и однозначно
идентифицировать экземпляр сущности. Часто в роли таких специальных атрибутов
выступают искусственно введенные атрибуты: шифр детали, код изделия и т.п.
Связи выступают в качестве средства, с помощью которого представляют
отношения между сущностями (ПО). Наиболее часто встречаются бинарные связи -
связи между двумя сущностями.
5.2. Классификация бинарных связей
1) 1:1 «Один к одному». Каждому экземпляру сущности А соответствует один
экземпляр сущности В и наоборот.
Пример: Если студент обучается в одном вузе, то связь
«СТУДЕНТ» ⇔ «СТУДЕНЧЕСКИЙ БИЛЕТ» является связью 1:1.
14
2) 1:М «Один ко многим».
Каждому экземпляру сущности А соответствует один или несколько
экземпляров сущности В.
Пример: «МАТЬ» ⇔ «РЕБЕНОК»
3) М:1 «Многие к одному». Каждый экземпляр сущности А связан с одним
экземпляром сущности В, а каждый экземпляр сущности В связан с одним или
несколькими экземплярами сущности А.
Пример: «РЕБЕНОК» ⇔ «МАТЬ»
3)
М:М «Многие ко многим». Каждый экземпляр сущности А связан с одним
или несколькими экземплярами сущности В и наоборот.
Пример: «ВРАЧ» ⇔ «ПАЦИЕНТ», «СТУДЕНТ» ⇔ «ПРЕПОДАВАТЕЛЬ».
5.3. Диаграмма ПО
Элементы диаграмм:
- сущность
книга
Пример:
- атрибут (идентифицирующий атрибут подчеркивается
)
15
Пример: код сотрудника
- связь
Пример:
Все элементы соединяются прямыми линиями.
При моделировании используются следующие правила:
• только три конструктивных элемента участвуют в отдельном проектном
представлении предметной области: сущность, атрибут, связь;
• выбор конструктивных элементов, особенно сущностей, должен производиться
таким образом, чтобы избежать избыточности данных.
При моделировании сложной предметной области проектировщик разбивает ее
на ряд предметных областей - локальных представлений, таким образом, чтобы
каждое представление содержало не более 6-7 сущностей.
Пример. Рассмотрим ПО «Служащий». Выделим на основании априорной
информации, полученной от постоянных пользователей ПО две сущности: Служащий
и Отдел
. Диаграмма ПО представлена на рис. 5.1.
Рис. 5.1. Диаграмма ПО «Служащий»
16
6. МОДЕЛИРОВАНИЕ ЛОКАЛЬНЫХ ПРЕДСТАВЛЕНИЙ
6.1. Выделение сущностей
Пусть в некотором локальном представлении выполняется описание поставок
товаров на склад. Предполагается, что в одной поставке может участвовать только
один поставщик, поставляя один вид товара, при этом поставщик может участвовать
в нескольких поставках. При обследовании предметной области было установлено,
что необходимая информация о поставках фиксируется в учетном журнале, выписка
из которого выглядит следующим образом:
Номер
поставки
Дата
поставки
Шифр
поставщика
Название
поставщика
Адрес
поставщика
Шифр
товара
Название
товара
Цена
за кг
Количество
252 19.03.00 21 ЧП "Смирнов" 180011,Воронеж 1 Мука 8 500
253 20.03.00 21 ЧП "Смирнов" 180011,Воронеж 2 Греча 15 200
254 20.03.00 21 ЧП "Смирнов" 180011,Воронеж 3 Рис 12 250
255 20.03.00 5 ЗАО "Сокол" 150111, Ростов 3 Рис 13 300
256 21.03.00 3 ЧП "Олимп" 150054,Ярославль 2 Греча 16 100
На основании этих данных была предложена модель ПО, представленная на
рис.6.1.:
Рис. 6.1. Схема предметной области «Поставка»
Анализ данной модели показывает, что реализация проекта ПО в таком
представлении ведет, с одной стороны, к большой избыточности данных (все о
поставщике повторяется в каждой новой поставке) и, с другой стороны, к
недостаточной гибкости системы (информация о поставщике и о товаре присутствует
в базе только тогда, когда сделана поставка). Устранение указанных недостатков
осуществляется выделением дополнительно сущностей Поставщик
и Товар. В
результате предлагается следующая модель ПО:
17
Рис. 6.2. Диаграмма предметной области «Поставка» после анализа
6.2. Выбор идентифицирующего атрибута
Как уже отмечалось ранее, при описании любой сущности всегда можно
выделить атрибут (совокупность атрибутов), который однозначно определяет
экземпляр сущности. Такой атрибут называют идентифицирующим или ключевым
(первичный ключ). Значение идентифицирующего атрибута уникально для каждого
экземпляра сущности, то есть не должно существовать двух или более экземпляров
сущностей с одинаковым значением первичного ключа. Обычно искусственно вводят
специальный идентифицирующий атрибут: шифр, индекс, номер, код. Остальные
атрибуты выступают в этом случае в роли описательных атрибутов.
6.3. Объединение локальных представлений
Пусть имеется "N" моделей – локальных представлений, требуется их
объединить и получить модель ПО более высокого уровня. Прежде всего необходимо
решить вопрос о порядке объединения моделей. Можно выполнить объединение за
один шаг (простое суммирование).
18
Обычно используется объединение, выполняемое в несколько шагов: бинарное
объединение.
При бинарном (парном) объединении N
1
объекта одного представления с N
2
объектами другого представления получается (N
1+
N
2
-Х) объектов, где Х – количество
совпадающих объектов.
Объединение моделей бинарным способом с учетом связей между отдельными
элементами называется агрегацией.
6.4. Способы агрегаций
1. Агрегатный объект определен в одном представлении как единое целое, а во
втором представлении рассматриваются его различные составные части.
2. Агрегатный объект как единое целое не представлен ни в одном из
локальных представлений, но в каждом локальном представлении рассматриваются
его различные составные части. О существовании объекта знает проектировщик.
Агрегация в этом случае выражается в определении объекта А и указании его
составных частей.
3. Один и тот же агрегатный объект описывается в каждом локальном
представлении, но составляющие части различаются.
Варианты агрегаций приведены на рис. 6.3.
Рис. 6.3. Варианты агрегаций
19
Пример.
Два цеха выпускают мебельные гарнитуры. Первое локальное представление
соответствует продукции первого цеха, а второе локальное представление – второго
цеха.
Первое локальное представление имеет вид, представленный на рис. 6.4.
Рис. 6.4. Диаграмма ПО первого цеха
Второе локальное представление имеет вид, представленный на рис. 6.5.
Рис. 6.5. Диаграмма ПО второго цеха
После объединения агрегатированием получим диаграмму, представленную на
рис.6.6.
20
Рис. 6.6. Диаграмма ПО после объединения агрегатированием
Обобщением называется абстракция данных, позволяющих рассматривать
класс различных однотипных объектов как один поименованный обобщенный тип
объекта. Если в предыдущем примере ввести класс Компонент
, обобщающий
различные составляющие, то окончательно получим модель, представленную на рис.
6.7.
Рис. 6.7. Диаграмма ПО после обобщения
Обобщение позволяет повысить гибкость системы за счет существенного
сокращения пространства поиска.