Простота проектирования	Вероятно, потребуется	Проектирование могут	Большинство
	квалифицированная	выполнить только опытные	пользователей (включая
	помощь, особенно при	специалисты-эксперты	конечных пользователей)
	определении необходимых		легко поймут логическую
	структур данных и при		структуру данных, а
	разработке связанных с		потому смогут
	ними прикладных		спроектировать базу
	программ		данных и отобразить её на
			физические структуры. К
			сожалению, недостаточное
			знание методов
			проектирования баз
			данных может привести к
			созданию слабых,
			неэффективных и негибких
			макетов
Доступ к базе данных	Стандартные методы	Здесь также доступ	Доступ может
	доступа посредством API:	осуществляется	варьироваться от
	приложение содержит	исключительно	использования API до
	встроенные вызовы	посредством API. Команды	таких интерактивных
	процедур для работы с	обрабатывают записи по	языков, как SQL или QBE.
	СУБД, команды	одной, но при этом они	Языки запросов позволяют
	обрабатывают записи	могут влиять и на	конечным пользователям
	последовательно, по одной,	зависимые записи.	опрашивать базу данных в
	хотя потенциально они	Благодаря использованию	произвольной манере.
	могут оказывать влияние и	специальных команд	Кроме того, SQL-команды
	на другие записи.	навигации по базе данных	могут внедряться в
	Дополнительные	пользователь может	прикладные программы
	программные конструкции	перемещаться к разным
	необходимы для навигации	местам иерархической
	по базе данных и	структуры.
	обработки наборов записей	Для обработки наборов
		записей могут
		потребоваться
		специальные программные
		конструкции
Стандарты	Для CODASYL-	Для иерархической модели	Для реляционных моделей
	совместимой модели	данных не существует	данных существует набор
	данных существует набор	строгого набора	стандартных концепций,
	стандартных концепций,	стандартных концепций, а	хотя между разными
	хотя между разными	реализации этой модели не	реализациями есть
	реализациями есть	соответствуют какому-	некоторые различия
	некоторые различия	либо особому стандарту

Приложение 4. Пример мифологического проекта базы данных

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

125

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

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

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

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

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

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

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

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

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

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

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

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

126

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

Приложение 5. Обобщенная методика проектирования реляционных баз данных

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

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

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

3)физическое проектирование [7, 17].

ЭТАП 1 Создание локальной концептуальное модели данных исходя из представлений о предметной

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

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

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

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

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

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

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

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

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

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

127

Документирование сведений о доменах атрибутов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

128

выполнить все транзакции, предусмотренные данным представлением пользователя.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

129

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЭТАП 6

130