Информационное обеспечение(лекции)

181

182

183

Приложение 4 - ПРИМЕР ИНФОЛОГИЧЕСКОГО ПРОЕКТА БАЗЫ ДАННЫХ

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

Информация предназначена для использования поваром и руководителем небольшого предприятия общественного питания, а также его посетителями.

1. Лобио по грузински

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

Фасоль стручковая (свежая или консервированная) 200, Лук зеленый

40, Масло сливочное 30, Зелень 10.

Выход 210. Калорий 725.

Рисунок П4.1 - Пример кулинарного рецепта

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

ихарактеристики проектируемой базы данных.

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

2.Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.

3.Ежедневное потребление блюд (расход): блюдо, количество порций,

дата.

Анализ объектов позволяет выделить:

–стержни Блюда, Продукты и Города;

–ассоциации Состав (связывает Блюда с Продуктами) и Поставки (связывает Поставщиков с Продуктами);

–обозначение Поставщики;

–характеристики Рецепты и Расход.

184

ER-диаграмма модели показана на рисунке П.4.2, а модель на языке ЯИМ имеет следующий вид:

БЛЮДА (БЛ, Блюдо, Вид)

ПРОДУКТЫ (ПР, Продукт, Калорийность) Поставщики (ПОС, Город, Поставщик) [ГородА] Состав [Блюда М, Продукты N] (БЛ, IIP, Вес (г))

Поставки [Поставщики М, Продукты И] (ПЯС, ПР, Дата П, Цена, Вес (кг))

ГОРОДА (Город, Страна) Рецепты (БЛ, Рецепт) {Блюда}

Расход (БЛ, Лата Р, Порций) {Блюда}

В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС – цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.

Рисунок П.4.2 - Инфологическая модель базы данных «Питание»

185

Приложение 5 - ОБОБЩЕННАЯ МЕТОДИКА ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

Процесс разработки баз данных включает три фазы:

1.концептуальное (инфологическое) проектирование;

2.логическое проектирование;

3.физическое проектирование.

ЭТАП 1

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

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

1.1. Определение типов сущностей

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

1.2. Определение типов связей

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

1.3.Определение атрибутов и связывание их с типами сущностей и

связей

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

1.4.Определение доменов атрибутов

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

1.5.Определение атрибутов, являющихся потенциальными и первичными ключами

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

1.6.Специализация или генерализация типов сущностей (необязательно)

Определение суперклассов и подклассов для типов сущностей (при необходимости).

186

1.7. Создание диаграммы «сущность-связь»

Разработка диаграмм «сущность-связь» (ЕR-диаграмм), содержащих концептуальное отражение представлений пользователей о предметной области приложения.

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

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

ЭТАП 2 Построение и проверка локальной логической модели данных на

основе представлений о предметной области каждого из типов пользователей

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

2.1.Преобразование локальной концептуальной модели данных в локальную логическую модель

Доработка локальных концептуальных моделей с целью удаления из них нежелательных элементов и преобразование полученных моделей в локальные логические модели данных. Удаление связей типа М:N, сложных связей, рекурсивных связей, множественных атрибутов, связей с атрибутами и избыточных связей. Перепроверка связей типа 1:1.

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

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

2.3.Проверка модели с помощью правил нормализации

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

2.4. Проверка модели в отношении транзакций пользователей

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

187

2.5. Создание диаграмм «сущность-связь»

Создание диаграмм «сущность-связь» (ER-диаграмм), являющихся локальным логическим представлением данных, используемых отдельными пользователями приложения.

2.6. Определение требований поддержания целостности данных

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

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

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

ЭТАП 3 Создание и проверка глобальной логической модели данных

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

3.1. Слияние локальных логических моделей данных в единую глобальную модель данных

Объединение отдельных локальных логических моделей данных в единую глобальную логическую модель данных организации. В круг решаемых при этом задач включены следующие:

–анализ имен сущностей и их первичных ключей

–анализ имен связей;

–слияние общих сущностей из отдельных локальных моделей;

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

–слияние общих связей из отдельных локальных моделей;

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

–проверка на наличие пропущенных сущностей и связей;

–проверка корректности внешних ключей;

–проверка соблюдения ограничений целостности;

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

–обновление документации.

188

3.2. Проверка глобальной логической модели данных

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

3.3.Проверка возможностей расширения модели в будущем

Определение вероятности внесения каких-либо существенных изменений

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

3.4.Создание окончательного варианта диаграммы «сущность-связь»

Создание окончательного варианта диаграммы «сущность-связь»,

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

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

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

ЭТАП 4 Перенос глобальной логической модели данных в среду целевой

СУБД

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

4.1. Проектирование таблиц базы данных в среде целевой СУБД.

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

4.2. Реализация бизнес правил организации в среде целевой СУБД

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

ЭТАП 5 Проектирование физического представления базы данных

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

5.1. Анализ транзакций

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

5.2. Выбор файловой структуры

Определение самого эффективного файлового представления для каждой из таблиц базы данных.

189

5.3. Определение вторичных индексов

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

5.4.Анализ необходимости введения контролируемой избыточности

данных

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

5.5.Определение требований к дисковой памяти

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

ЭТАП 6 Разработка механизмов защиты

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

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

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

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

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

ЭТАП 7 Организация мониторинга и настройка функционирования системы

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

190