Базы данных, знаний и экспертные системы Калабухов ЕВ, БГУИР 2007 (Мет пособие)

возможного расширения);

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

•определение требований поддержки целостности данных;

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

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

На втором этапе логического проектирования проводится создание и

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

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

•проверка глобальной логической модели данных;

•проверка возможностей расширения модели в будущем (определение частей модели, которые будут расширяться в будущем, согласование расширений с пользователями);

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

•проверка и обсуждение глобальной логической модели с конечными

пользователями.

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

31

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

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

Этап 1. Перенос глобальной логической модели в среду целевой СУБД:

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

•реализация бизнес-правил (зависит от СУБД, лучший вариант – полное использование возможностей СУБД, не переносить бизнес-правила в приложения).

Этап 2. Проектирование физического представления БД:

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

•выбор файловой структуры (для оптимальной файловой организации);

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

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

32

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

•определение требований к дисковой памяти (в том числе учет требований для обоснования приобретения нового оборудования).

Этап 3. Разработка механизмов защиты:

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

•определение прав доступа.

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

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

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

33

4. МОДЕЛИ ДАННЫХ

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

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

4.1. Определение и классификация моделей данных

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

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

Модель данных включает в себя следующие части:

•структурная часть – набор правил, по которым может быть построена БД;

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

•ограничения поддержки целостности данных (необязательная часть). Модели данных можно разделить на три категории:

1)концептуальные (объектные) модели данных – описание данных высокого уровня (уровня объектов): модель типа «сущность-связь» или ER-модель (Entity-Relationship), объектно-ориентированная модель

34

(состояние + поведение объектов), функциональная модель;

2)логические модели данных (модели данных на основе записей) – БД состоит из логических записей фиксированного формата: сетевая модель данных (network), иерархическая модель данных (hierarchical) и реляционная модель данных (relational) (хотя и не в такой степени, как две предыдущие – табличный подход (как в представлении данных для пользователя, так и в обработке (декларативный подход (какие данные надо извлечь), а не навигационный (по одной записи))) и неявные связи между записями – ближе к объектным моделям);

3)физические модели данных – описывают, как данные хранятся в компьютере (информация о структуре записей, порядке расположения записей и путях доступа к ним): обобщающая модель (unifying), модель

памяти кадров (frame memory).

Для отображения ANSI-SPARC архитектуры существует три модели данных:

•внешняя модель данных (предметная область пользователей),

•концептуальная модель данных (логическое представление о данных),

•внутренняя модель данных (представление концептуальной модели

средствами конкретной СУБД).

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

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

4.2.1. Семантическое моделирование данных

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

35

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

Общий подход к проблеме семантического моделирования состоит из четырех этапов:

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

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

–гибкость интерпретации данных в семантическом моделировании).

3)Вывод множества формальных правил целостности для работы с формальными объектами.

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

Идеи семантического моделирования могут быть полезны при

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

36

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

4.2.2. ER-модель (модель типа «сущность-связь» или «объект/отношение»)

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

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

4.2.2.1.Концепции ER-модели

ВER-модели выделены следующие три концепции:

1) Объекты (типы сущностей):

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

37

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

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

Типы объектов классифицируются как сильные и слабые:

•слабый тип объекта (дочерний, зависимый или подчиненный) – тип объекта, существование которого зависит от какого-то другого типа объекта;

•сильный тип объекта (родительский, владелец или доминантный) – тип объекта, существование которого не зависит от какого-то другого типа объекта.

Представление объектов на диаграмме: сильный тип объекта – прямоугольник, с именем внутри него; слабый тип объекта – прямоугольник с двойным контуром (деление объектов на сильные и слабые – по желанию проектировщика).

2) Свойства (атрибуты):

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

Свойства делят по характеристикам:

•простые и составные: простое свойство состоит из одного компонента с независимым существованием (такое свойство – атомарное (не может быть разделено на более мелкие компоненты); например «зарплата», «пол»); составное свойство – состоит из нескольких компонентов, каждый из которых характеризуется независимым существованием

38

(могут быть разделены на более мелкие части (например, «адрес»), но решение о представлении такого атрибута (как простой или составной) зависит от проектировщика);

•однозначные и многозначные: однозначное свойство – свойство, которое может содержать только одно значение для одного объекта; многозначное свойство – может содержать несколько значений для одного объекта (например, «телефон компании»);

•производные и базовые: производное свойство - представляет значение, производное от значения связанного с ним свойства или некоторого множества свойств, принадлежащих некоторому типу объектов (не обязательно одному), например, «сумма деталей», «возраст сотрудника»; базовое – не зависит от других свойств.

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

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

39

3) Отношения (типы связей):

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

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

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

Рисунок 4. Свойство отношения (составного объекта). Унарное отношение.

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

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

40