Контрольные вопросы к части 1.

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

2. Что представляет собой модель предметной области?

3. Что такое концептуальная модель БД?

4. Какие модели данных поддерживают современные СУБД?

5. Определите понятия первичного, возможного и внешнего ключа.

6. Какие ограничения накладывает на отношения БД реляционная модель?

7. Определите понятия схемы отношения, его степени и мощности.

8. Что входит в понятие структуры отношения?

9. Какие существуют способы ввода данных в БД?

10. Какие способы поддержания ссылочной целостности данных есть в Access ?

11. Чем отличается сортировка от индексации и что между ними общего?

12. Чем отличается импорт данных от их присоединения?

13. Какие два основных стандарта языка запросов вам известны? Отличаются ли они по своим возможностям?

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

15. Для каких целей используются экранные формы? Какие виды экранных форм вам известны?

16. Какие элементы и в каких целях используются в экранных формах?

17. С какой целью создаются отчеты? Какие типы отчетов вам известны?

18. Назовите известные вам виды меню и способы их создания.

19. Как осуществляется программирование в Access?

20. Что представляют собой макросы в Access?

21. В каких случаях рекомендуется использовать макросы, а в каких модули?

Часть II Проектирование баз данных (бд) Цели проектирования:

1. Обеспечить возможность хранения в базе данных всех необходимых данных.

2. Исключить избыточность данных.

3. Свести к минимуму количество хранимых в базе данных отношений.

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

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

Для достижения второй цели не следует исключать дублирование данных вообще. Да это и невозможно сделать без потери семантики предметной области. Необходимо исключить лишь избыточное дублирование. Например, информация в отношении ПРЕПОДАВАТЕЛИ, имеющем атрибуты ФИО и Кафедра, не является избыточной, хотя против фамилий нескольких преподавателей института может стоять название одной и той же кафедры. Удалив такие повторения, мы бы потеряли возможность узнать , на какой кафедре работают те или иные преподаватели. Если же в отношение ПРЕПОДАВАТЕЛИ добавить еще атрибут Телефон_Кафедры, то повторение одинаковых номеров телефона для одной и той же кафедры является избыточной информацией, т.к. связь между кафедрой и телефоном указывается в нескольких строках. Проблема исключения избыточности в подобных случаях решается разложением одного отношения на два. Эта операция называется декомпозицией отношений. Декомпозиция отношений – это стандартная процедура при проектировании БД. В рассматриваемом примере получим два отношения: ПРЕПОДАВАТЕЛИ (ФИО, Кафедра) и КАФЕДРА (Название_Кафедры, Телефон_Кафедры). В отношении КАФЕДРА телефон каждой кафедры будет указан только один раз.

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

Рассмотрим подробнее проблемы, связанные с использованием единственного отношения, и причины, по которым проектировщики стремятся привести отношения, составляющие БД, к НФБК.

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

Сведения о книге состоят из ее шифра – Шифр, Названия книги – Назв, автора или авторов книги – Авт, Года издания – Год, количества экземпляров , имеющихся в библиотеке – Экз.

Сведения о читателе - это Фамилия и инициалы читателя – ФИО, номер его читательского билета - Билет, номер контактного телефона – Тел.

Кроме того, известны даты закрепления книг за читателями – Дата. Атрибут дата относится в равной мере как к книге, так и к читателю.

Попытаемся поместить все эти данные в одно отношение.

Таблица 2.1. Отношение «Библиотека».

Билет	ФИО	Тел	Шифр	Назв	Авт	Год	Экз	Дата
123	Иванов И.И.	238-80-01	Ч-15	Чайка	Чехов А.	1938	15	15.01.02
123	Иванов И.И.	238-80-01	Т-2	Воскресенье	Толстой Л..	1959	7	15.01.02
123	Иванов И.И.	238-80-01	Д-21	Идиот	Достоевский Ф.	1970	3	20.03.02
546	Петров П.П.	215-18-04	ТА-12	Аэлита	Толстой А.	1976	8	16.02.02
546	Петров П.П.	215-18-04	ТА-8	Петр I	Толстой А.	1948	2	25.02.02
108	Сидоров С.С.	115-13-40
200	Панов П.П.	215-20-02
	Алексеев А.А.	110-11-22
			Б-111	Собачье сердце	Булгаков М.	1970	20
			Б-112	Мастер и Маргарита	Булгаков М.	1972	10

Таблица представляет собой экземпляр универсального отношения проектируемой БД, т.е. отношения, которое включает все необходимые атрибуты БД и всю имеющуюся на текущий момент информацию. Видно, что таблица содержит как полностью заполненные строки, так и строки, представляющие собой сведения о читателях, которые в настоящий момент не имеют на руках книг или сведения о книгах, которые никто не читает. Большой объем информации в таком отношении является избыточным. Из-за избыточности данных возникает проблема их обновления. Так, если у читателя Петрова изменится номер телефона, то потребуется внести изменения в 2 записи, а если телефон изменится у Иванова, то в 3. Существует и проблема удаления. Например, нельзя удалить целиком первую запись, если Иванов Сдал книгу «Чайка», т.к. в этом случае мы потеряем информацию об этой книге. Можно заменить пустыми значениями значения полей Билет, ФИО и Тел. Но так сделать можно только в случае, если Иванов брал и другие книги, в противном случае он исчезнет из списка читателей библиотеки. Таким образом, операция, связанная с возвратом книги, выполняется по-разному в зависимости от данных, содержащихся в таблице. Неоднозначно выполняется и процедура добавления записи в БД. Пусть Сидоров взял книгу Толстого «Воскресенье». Нельзя просто добавить соответствующую строку в БД, поскольку сведения о Сидорове уже есть в БД, но есть и информация о книге «Воскресенье», т.к. ее уже раньше взял Иванов. Тем не менее придется приписать информацию о книге к строке с информацией о Сидорове. Если бы книгу никто не брал, то две отдельные неполные записи о книге «Воскресенье» и о читателе Иванове пришлось бы заменить одной, добавив значение поля Дата.

108

Сидоров С.С.

115-13-40

Т-2

Воскресенье

Толстой Л..

1959

7

20.04.02

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

Определим понятие функциональной зависимости(ФЗ).

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

Функциональная зависимость атрибута В от атрибута А в математической форме обозначается как А → В, а в графической

Рис.2.1

Рассмотрим функциональные зависимости, существующие между атрибутами отношения «Библиотека». Эти ФЗ вытекают из семантики предметной области.

Шифр однозначно определяет как автора книги, так и ее название, год издания и количество экземпляров, имеющихся в библиотеке. Номер читательского билета однозначно определяет ФИО читателя и номер его телефона. Функциональной зависимости между ФИО читателя и номером телефона нет, т.к. фамилии и инициалы некоторых читателей большой библиотеки могут и совпадать. Не существует и ФЗ между атрибутами Тел и ФИО, т.к. один и тот же телефон может быть телефоном разных читателей, если, предположим, они проживают в одной квартире. Наконец атрибут Дата находится в функциональной зависимости от сложного атрибута Шифр+Билет, т.к. это дата закрепления определенной книги за определенным читателем, если, конечно, читатель не берет одну и ту же книгу несколько раз. Рассуждая подобным образом, изобразим диаграмму функциональных зависимостей, отображающую ФЗ между атрибутами отношения.

Рис.2.2

Эти же зависимости в математической форме могут быть представлены следующим образом:

1. Шифр → Авт

2. Шифр → Назв

3. Шифр → Год

4. Шифр → Экз

5. Билет → ФИО

6. Билет→ Тел

7. Шифр, Билет → Дата

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

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

Определим, находится ли в НФБК отношение «Библиотека». Ключом отношения является набор атрибутов (Шифр, Билет), поскольку атрибут Шифр однозначно определяет значения атрибутов Авт, Назв, Год и Экз, атрибут Билет однозначно определяет значения таких атрибутов, как ФИО читателя и Тел – номер его телефона, а для определения даты выдачи книги требуются оба значения – Шифр и Билет. Детерминанты отношения – это левые части всех функциональных зависимостей, если слева находится один атрибут. Если же левая часть представляет собой совокупность атрибутов, то она является детерминантом только в случае, если нет зависимости правой части этой ФЗ от части этих атрибутов. В нашем случае детерминантами отношения являются атрибуты Шифр, Билет и составной атрибут (Шифр, Билет), но только последний является ключом. Следовательно, отношение «Библиотека» не находится в НФБК и его следует подвергнуть декомпозиции. Декомпозиция, которая нас интересует, называется декомпозицией без потерь при естественном соединении. Выполняется она следующим образом.

Пусть имеем отношение R (A, B, C, D, E, …). Атрибут А является первичным ключом этого отношения, от него функционально зависят все остальные атрибуты. Кроме того, существует ФЗ C  D, наличие которой мешает отношению R находиться в НФБК, т.к. С, являясь детерминантом отношения, не является его ключом. В этом случае следует разбить отношение на два: R1 (C, D) и R2 (A, B, C, E, …). Отношение R1 является проекцией отношения R. Атрибуты функциональной зависимости, на которую выполняется проекция, переходят в новое отношение, при этом атрибут (совокупность атрибутов) левой части остается также и в исходном отношении.

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

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

Избыточная ФЗ, как не содержащая уникальной информации может и должна быть удалена из набора ФЗ. Рассмотрим, как выявляется наличие в отношении избыточных ФЗ и какие приемы используются для их удаления. Найти и удалить избыточные ФЗ можно с помощью следующих правил, которые называются правилами вывода :

• Транзитивность. Если имеем ФЗ A  В и B  C, то существует ФЗ A  С, которая называется транзитивной. Транзитивная зависимость является избыточной и может быть удалена из отношения. Нестандартным случаем транзитивной зависимости является циклическая зависимость A ↔ B, B ↔ C, C ↔ A. При исключении любой из этих ФЗ две оставшиеся перестают быть избыточными.

• Объединение. Если имеем ФЗ A  В и А  C, то существует ФЗ A  В, С. Это правило позволяет сократить количество ФЗ отношения путем замены нескольких ФЗ с одинаковыми левыми частями одной.

• Добавление. Если имеем A  В, то ФЗ A, Z  B является корректной, но избыточной. Избыточной является также ФЗ A, X  В, X.

• Декомпозиция. Если имеем ФЗ A  В, C то ее можно заменить двумя ФЗ: A  В и A  С.

• Псевдотранзитивность. Если имеем ФЗ A  В и B, C  X, то существует ФЗ A, C  С, которая называется псевдотранзитивной ФЗ и является избыточной.

Для устранения избыточных ФЗ в отношении «Библиотека» дважды применим правило объединения – сначала по отношению к ФЗ 1, 2,3, 4, а затем по отношению к ФЗ 5, 6. В итоге получим:

1. Шифр → Авт, Назв, Год, Экз

2. Билет → ФИО, Тел

3. Шифр, Билет → Дата

В графическом виде эти зависимости представлены на рис. 2.3.

Рис.2.3.

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

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

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

Получив минимальное покрытие, можно приступать к декомпозиции отношения. В нашем случае кандидатов на проекцию два – это правила 1 и 2. Выберем, например, первое. Получим два отношения: отношение R1 с атрибутами Шифр, Авт, Назв, Год, Экз, между которыми существует единственная ФЗ:

Шифр → Авт, Назв, Год, Экз,

и отношение R2 с атрибутами Билет, ФИО, Тел, Шифр, Дата, в котором есть две ФЗ:

Билет → ФИО, Тел

Шифр, Билет → Дата

В графическом виде функциональные зависимости между атрибутами отношений R1 и R2 представлены соответственно на рисунках 2.4 и 2.5.

рис. 2.4

рис. 2.5

Отношение R1 находится в НФБК, поскольку ФЗ всего одна, и левая ее часть является как детерминантом, так и ключом этого отношения. Отношение R2 в НФБК не находится, поскольку Билет, являясь его детерминантом, не является ключом. Выполним проекцию отношения R2 на ФЗ Билета → ФИО, Тел. Получим отношение R3 с атрибутами Билет, ФИО, Тел и ФЗ

Билет → ФИО, Тел ,

в оставшемся отношении R4 с атрибутами Шифр, Билет, Дата, также имеется только одна ФЗ, а именно:

Шифр, Билет → Дата.

Диаграммы ФЗ отношений R3 и R4 изображены на рис. 2.6 и 2.7 соответственно.

рис 2.6

рис. 2.7

Отношения R3 и R4 находятся в НФБК, как и любое отношение, в котором существует только одна ФЗ. Процесс декомпозиции завершен. Мы получили три отношения: R1, R3, R4. Отношение R1, учитывая состав его атрибутов, назовем Книга, отношение R3 – Читатель, а отношение R4 – Читает. Итак, вместо одного универсального отношения Библиотека мы получили 3 отношения. Привели ли наши действия к устранению потенциальных аномалий, присущих БД «Библиотека»?

При наличии в БД единственного отношения Библиотека возникали проблемы с изменением номера телефона читателя. Номер телефона надо было изменить столько раз, сколько книг взял читатель. Теперь, после разбиения отношения на три, нужно изменить номер телефона только в одной строке отношения Читатель. Существовала и проблема удаления строк при возврате книге читателем. Теперь, если читатель возвращает книгу, это требует удаления строки отношения Читает, тем самым разрывается связь между читателем и книгой, но сведения о книге, находящиеся в отношении Книга не исчезают, то же можно сказать и по поводу сведений о читателе, хранящихся в отношении Читатель. Аномалия добавления тоже исчезла. Теперь не может быть частично заполненных строк в каждом из отношений. Если в библиотеку записывается новый читатель, то строка добавляется в отношение Читатель, и эта операция не затрагивает другие отношения БД. Если библиотека получила новую книгу, то сведения о ней помещаются в отношение Книга, а в случае, когда выполняется операция выдачи книги читателю, добавляется строка со сведениями о том, кто, какую книгу и когда взял, в таблицу Читает. При этом и сведения о книге и сведения о читателе, которому ее выдают, уже есть в БД, соответственно в отношениях Книга и Читатель, Т.о. можно констатировать, что разбиение исходного универсального отношения на три отношения привело к автоматическому устранению перечисленных аномалий вставки, удаления и обновления.

Рассмотренный нами случай является чрезвычайно простым. Реально функциональных зависимостей, которые мешают отношению находиться в НФБК, может быть гораздо больше двух. В этом случае оказывается не безразличным, какую из ФЗ выбрать для первой проекции. Обычно при выборе ФЗ для проекции руководствуются следующим правилом. Ищут цепочки вида АВС, и используют крайнюю правую зависимость. Это позволяет избежать выбора ФЗ, правая часть которых полностью или частично является детерминантом другой ФЗ. Чем же опасен такой выбор? Попробуем, имея цепочку АВС, выполнить проекцию на ФЗ АВ. Получим отношение R1(A,B) и отношение R2(A,С). Оба эти отношения находятся в НФБК, но ни одно из них не содержит ФЗ ВС, присутствующую в исходном отношении. Таким образом, в результате декомпозиции произошла потеря одной из ФЗ исходного отношения, что является недопустимым, поскольку искажается семантика предметной области.

Подведем итог. Метод проектирования БД, который носит название метода декомпозиции, состоит из следующих шагов:

1. Разработка универсального отношения.

2. Определение всех ФЗ между атрибутами отношения.

3. Исключение избыточных ФЗ и получение минимального покрытия.

4. Определение того, находится ли отношение в НФБК.

• если да, то все оставить без изменения,

• если нет, то выбрать ФЗ для проекции и разложить отношение на два.

5. Повторить шаг 4 для каждого нового, полученного при разложении, отношения

Процесс завершается, когда окажется, что все полученные отношения находятся в НФБК.

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

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

• если все его атрибуты присутствуют в другом отношении, например, имеем БД, состоящую из отношений R1(A,B), R2(B,C,Y,Z), R3(A,B,D), отношение R1 в этом наборе является избыточным, поскольку оба его атрибута содержатся в отношении R3.

• если все его атрибуты присутствуют в отношении, которое может быть получено из других отношений БД с помощью последовательности операций соединения над ними. Пусть имеем БД из пяти отношений: R1(A,C,X), R2(D,K,F), R3(D,E,G,H), R4(A,B,D), R5(A,B,E,G). Если применить операцию соединения к отношениям R3 и R4, то получим отношение R6(A,B,D,E,G,H). Поскольку в этом отношении содержатся все атрибуты отношения R5, то R5 является избыточным отношением. Если бы мы применили операцию соединения к паре отношений R3,R5 или R2,R5, то избыточным оказалось бы отношение R4.

Проведем анализ полученного набора отношений БД Библиотека. Смысловая связность атрибутов, составляющих каждое из отношений, не нарушена. В отношении Читатель, присутствуют атрибуты, характеризующие читателя – его ФИО, номер билета и телефон. Отношение Книга содержит только атрибуты, характеризующие библиотечную книгу: ее название, шифр, автор, год издания и количество имеющихся в библиотеке экземпляров этой книги. Отношение Читает, являясь связным отношением, содержит первичные ключи объектных отношений Книга и Читатель, а также атрибут Дата, представляющий собой дату закрепления книги за читателем и относящийся в равной степени как к книге, так и к читателю. Мы пока не имеем перечня предполагаемых запросов к БД Библиотека, поэтому не можем дать заключение о соответствии полученного набора отношений предполагаемым запросам. Однако, если бы в перечне присутствовал запрос: «Кто из читателей является читателем библиотеки уже более 10 лет?», потребовалась бы коррекция набора атрибутов БД и ФЗ, пришлось бы добавить атрибут ДатаЗаписи, который функционально зависит от номера читательского билета и должен размещаться в отношении Читатель. Если при возврате книги читателем строка с указанием того, какую книгу и когда он брал, удаляется из таблицы Читает, то мы не сможем получить правильный ответ на вопрос: «Кто из читателей брал книги в предыдущем месяце?», если часть читателей эти книги уже вернули. Для того, чтобы ответ на такой вопрос стал возможным, надо добавить в отношение Читает атрибут ДатаВозврата, функционально зависящий, как и атрибут Дата (изменим его имя на ДатаЗакрепления) от совокупности атрибутов Шифр и Билет. Теперь удалять строки из отношения Читает не будем. Если читатель еще не вернул книгу, будет заполнено только поле ДатаЗакрепления, а когда книга возвращается в библиотеку, появляется значение и в поле ДатаВозврата. Таким образом, анализ возможных запросов к БД приводит нас к необходимости добавления в БД двух новых атрибутов: ДатаВозврата и ДатаЗаписи. Первый атрибут добавим в таблицу Читает, а второй – в таблицу Читатель. Анализ запросов может потребовать и добавления в БД новых связей между таблицами и даже новых, обычно связных, отношений. Это означает, что при проектировании мы упустили из виду какие-то зависимости, существующие между атрибутами предметной области, а анализ запросов помог обратить на них внимание.

Рассмотрим теперь набор ФЗ, присутствующих в отношениях, составляющих БД Библиотека. В отношении Книга присутствует единственная ФЗ - Шифр → Авт, Назв, Год, Экз, в отношении Читатель ФЗ Билет → ФИО, Тел , в отношении Читает также имеется только одна ФЗ, а именно: Шифр, Билет → Дата. При этом каждая ФЗ присутствует только в одном отношении, а набор из трех ФЗ, распределенный по трем отношениям совпадает с исходным минимальным покрытием.

Избыточных отношений нет, поскольку то, что атрибуты ни одного из отношений полностью не присутствуют в другом, очевидно. Что же касается второго случая, то выполнять операции соединения имеет смысл, если атрибут, находящийся в одном отношении, находится также и в другом. Это в полной мере относится к атрибутам правых частей ФЗ, что же касается атрибутов левых частей, то их присутствие в нескольких отношениях может быть оправдано наличием связи между отношениями, устанавливаемой по этим атрибутам. В нашем случае атрибуты Авт, Назв, Год, Экз, находятся только в отношении Книга, атрибуты ФИО и Тел – только в отношении Читатель, а атрибут Дата – только в отношении Читает. Атрибут Шифр присутствует в двух отношениях – Книга и Читает, а атрибут Билет – в отношениях Читатель и Читает, но оба используются для связи между отношениями. Связи между отношениями БД Библиотека изображены на рис. 2.8.

Рис. 2.8. Связи между отношениями БД Библиотека.

Вообще, отношение, которое является связующим звеном между двумя объектными отношениями, и обе эти связи 1 : n, как в нашем случае, не может быть исключено, как избыточное, даже, если все его атрибуты полностью входят в какое-то другое отношение. Это определяется тем, что в любой СУБД можно установить межтабличные связи 1 : 1 или 1 : n, но не m : n.

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

На стадии программной реализации выполняются следующие действия.

1. Средствами выбранной для реализации СУБД вводятся описания (схемы) всех составляющих базу данных отношений.

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

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

4. БД заполняется отладочными данными

5. Производится тестирование прикладной системы.

Этап логического проектирования БД предшествует этапу ее реализации в рамках выбранной СУБД и является важным этапом, поскольку грамотный проект позволяет упростить процесс реализации системы и избежать большинства проблем при ее эксплуатации. Однако, рассмотренный нами декомпозиционный метод проектирования работает не всегда. Считается [2], что, если количество атрибутов предметной области более двадцати, то метод становится излишне громоздким и сложным для применения. В этом случае рекомендуется использовать ER- метод.