2. Третий этап проектирования базы данных: задание первичных и альтернативных ключей

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

2. Четвертый этап проектирования базы данных: приведение модели к требуемому уровню нормальной формы

На этом этапе проектирования выполняется главная задача — нормализация отношений. В процессе нормализации концепту­альные требования группируются в таблицы. На этом этапе про­ектирования концептуальные требования для каждого структур­ного подразделения могут быть сведены либо в одну таблицу, ли­бо в несколько таблиц. Здесь также решается вопрос ликвидации избыточной информации, то есть концептуальные требования, используемые несколькими структурными подразделениями, сводятся в одну таблицу с одновременным добавлением ключей лля перехода в другие таблицы (для других структурных подразде- ™*)- Таким образом добиваются существенного сокращения °бьема памяти. На этом этапе также решается вопрос о том, какие блицы будут справочниками, то есть информация в этих табли­цах не изменяется или изменяется очень медленно. Следует иметь ^вНцу, что чрезмерное увеличение количества таблиц приводит к нот^{130 0бщей идеи} создания базы данных, и сама база данных ста­ится трудной для понимания и управления. Для базы данных

объема предприятия оптимальное количество таблиц должно быть не более сорока или пятидесяти.

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

1. Первая нормальная форма

Для таблицы будут выполнены условия первой нормальной фор­мы, если:

• каждое поле (концептуальное требование) неделимо;

• отсутствуют повторяющиеся поля или группы полей.

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

2. Вторая нормальная форма Условия второй нормальной формы:

• выполняются условия первой нормальной формы;

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

• все поля зависят от первичного ключа;

• первичный ключ не должен быть избыточным.

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

3. Третья нормальная форма

Условия третьей нормальной формы:

• выполняются условия второй нормальной формы;

• каждое не ключевое поле не должно зависеть от другого не ключевого поля.

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

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

2. Пятый этап проектирования базы данных: физическое описание модели

На этом этапе каждая таблица, созданная на четвертом этапе:

• получает свое имя, под которым она будет храниться в базе данных;

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

• для каждого ключа, как первичного, так и внешнего, опре­деляются его характеристики: Primary' — первичный (обяза­тельно уникальный), Candidate — альтернативный (обяза­тельно уникальный), Maintain — внешний (может быть как уникальным, так и не уникальным) |5].

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

задачей.

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

6. СРЕДСТВА БЫСТРОЙ РАЗРАБОТКИ ПРИЛОЖЕНИЙ

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

С целью увеличения производительности труда программиста и сокращения времени создания прикладных программ разрабо таны средства быстрой раоработки приложений — RAD (Rapid Application Development). Разработка компьютерных программ с использованием RAD предусматривает два этапа:

• создание интерфейса;

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

Наиболее трудоемкая часть работы программиста — создание интерфейса — автоматизирована и сводится к размещению эле­ментов интерфейса на специальном поле формы. При этом геометрические размеры и место расположения элемента интер­фейса описываются программными кодами автоматически Изменение размеров и положения элемента интерфейса произ­водится традициошшми приемами, предусмотренными в WIN­DOWS, с автоматической корректировкой программных кодов. Программисту остается написать в специальном месте про­граммные коды, которые описывают реакцию на выбор элемен та интерфейса. Например: если выбрана кнопка «Поиск», то про­граммные коды, описывающие реакцию на выбор кнопки, содержат описание одного из методов поиска.

Среда программирования, содержащие средства RAD, долж ны иметь:

• объектно-ориентированный язык программирования;

• визуальные средства разработки, то есть средства графиче^ ского создания интерфейса;

• возможность создания индивидуальных элементов интер­фейса на основе стандартных элементов;

е возможность создания программных продуктов по техноло­гии клиент-сервер;

• поддержку* различных протоколов обмена дашшми.

7. СРАВНИТЕЛЬНЫЙ АНАЛИЗ СИСТЕМ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ (СУБД)

/. Access

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

2. SQI.-Server

Эта СУБД обеспечивает высокую степень защиты данных, как от случайных потерь, так и от несанкционированного доступа, об­ладает развитыми средствами обработки данных и хорошим быстродействием. SQL-Server предназначен для хранения боль­шого объема данных.

2. Visual Basic

Visual Basic не требовательна к техническим характеристикам персонального компьютера. Так как Visual Basic является продуктом фирмы Microsoft, то легко интегрируется со всеми приложениями Microsoft Office и многими приложениями, интегрированными в WINDOWS. Предназначен Visual Basis для создания небольших приложений, в которых не требуются боль­шие вычисления и серьезная обработка данных.

4- Visual C++

самая екоростная среда программирования, обеспечиваю- Шая выполнение расчетов и обработку данных любой сложно­сти, совместима практически со всеми известными приложени-

5. Visual FoxPro

СУБД Visual FoxPro предназначена для создания приложений баз данных объема предприятия, обладает хорошим быстродей­ствием и устанавливается на различные платформы [5J.

8. ПРИМЕР

Создать базу данных для книжного издательства.

На первом этапе проектирования базы данных изучается, структура организации (издательства) и собираются концепту­альные требования. В результате изучения организации работы издательства выяснилось, что имеются следующие рабочие груп-* пы (отделы), которые используют информ щию по учету издава­емых книг:

• группа маркетинга — хранит, редактирует каталог изданных книг и создает различные рекламные листовки, буклеты и т.д.;

• торговая группа — подбирает комплект книг для заказчика, оформляет заказ на покупку книг и фиксирует всех заказчик ков (покупателей);

• группа планирования - определяет список книг, которые i надо издать, веде переговоры и заключает договоры с авто* рами книг;

• материальная группа — по оплаченному счету выписывае1| расходную накладную и выдает книги покупателю.

Для нормальной работы группы маркетинга необходима еле-1 дующая информация (концептуальные требования):

• фамилия, имя и отчество автора (авторов) книги;

• название книги;

• место (город) издания книги;

• год издания книги;

• объем книги в страницах;

• цена одного экземпляра книги;

• тип оформления книги;

• сведения о торговых скидках.

Для нормальной работы торговой группы необходима слеДУ "| ющая информация (концептуальные требования):

_а) сведения о продавце:

• фамилия, имя и отчество продавца;

• должность;

• дата рождения;

• оклад;

• образование;

• дата поступления на работу;

б) сведения о клиенте:

• наименование фирмы;

• адрес фирмы;

• телефон;

• факс;

• фамилия, имя и отчество покупателя;

• признак юридического лица;

в) сведения о заказе:

• дата оформления заказа;

• наименование книги;

• количество;

• цена за один экземпляр;

• размер торговой скидки;

• сумма заказа;

• способ оплаты.

Для нормальной работы материальной группы необходима следующая информация (концептуальные требования):

^а) сведения о счете:

• дата оплаты;

• оплаченная сумма;

• пометка об оплате;

б) сведения о продаже:

• Дата отпуска книг со склада;

• наименование книги;

• количество;

• Цена за один экземпляр;

• размер торговой скидки;

• сумма заказа;

• способ оплаты;

• номер склада;

• фамилия, имя и отчество кладовщика;

• фамилия, имя и отчество представителя заказчика, кому выдан заказ;

• паспортные данные представителя заказчика.

Для нормальной работы группы планирования необходима следующая информация (концептуальные требования):

• фамилия, имя и отчество автора (авторов);

• образование;

• ученая степень;

• ученое звание;

• дата рождения;

• адрес автора (авторов);

• наименование книги;

• дата сдачи рукописи;

• объем книги (в печатных листах);

• номер договора;

• сведения об авторских правах.

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

На втором этапе проектирования базы данных определяю сущности и взаимосвязи между сущностями. В результате ана­лиза концептуальных требований получим следующую схему (рис. 1.12).

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

Исходя из рис. 1.12, можно сделать вывод, что сущность Кли­ент будет родительской, так как один клиент может сделать не­сколько заказов и оплатить несколько счетов, в то время как каж­дый заказ принадлежит только одному клиенту и оплату счета производит один клиент. Поэтому сущность Клиент может иметь только первичный ключ. Сущности Заказ и Счет будут до­черними и должны иметь как первичные, так и внешние ключи. Проведя аналогичные рассуждения для остальных сущностей, получим следующие концептуальные требования (табл. 1.1).

Эти концептуальные требования распределены на несколько частей-прообразов таблиц: «Клиент», «Заказ», «Счет», «Прода­жа», «Продавец», «Автор», «Каталог» и т. д.

Таблица 1.1.

Сущность	Ключ	Атрибут
Клиент	Первичный	номер клиента наименование фирмы адрес фирмы телефон фахс фамилия, имя и отчество покупателя признак юридического липа
Заказ	Первичный	номер заказа
	Внешний	номер клиента
	Внешний	номер продавца
	Внешний	номер издания (книги) дата оформления заказа наименование книги количество цена за один экземпляр размер торговой скидки сумма заказа способ оплаты
Счет	Первичный	номер счета
	Внешний	номер клиента
	Внешний	номер накладной дата оплаты оплаченная сумма пометка об оплате

Таблица 1.1. Продолжение

Сущность Ключ Атрибут

Продажа Первичный номер накладной Внешний номер счета

дата отпуска книг со склада наименование книги количество

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

фамилия, имя и отчество кладовщика фамилия, имя и отчество представител заказчика

паспортные данные представителя заказчи

Продавец Первичный номер продавца

фамилия, имя и отчество продавца

должность

дата рождения

оклад

образование

дата поступления на работу

Автор Первичный номер автора

фамилия, имя и отчество автора

(авторов)

образование

ученая степень

ученое звание

дата рождения

адрес автора (авторов)

наименование книги

дата сдачи рукописи

объем книги (в печатных листах)

номер договора

сведения об авторских правах

Каталог Первичный номер издания (книги) Внешиий номер автора

фамилия, имя и отчество автора (авторов) книги наименование книги место (город) издания книги год издания книги объем книги в страницах иена одного экземпляра книги тип оформления книги

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

Условия первой нормальной формы таблицы:

• каждое поле должно быть неделимо;

• отсутствуют повторяющиеся поля или группы полей.

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

Таблица «Заказ» н таблица «Продажа» имеют повторяющиеся поля: наименование книги, количество, цена за один экземпляр, размер торговой скидки, сумма заказа, способ оплаты.

Кроме того, поле «наименование книги» повторяется в табли­цах «Автор» и «Каталог», а поле «цена одного экземпляра книги» — в таблице «Каталог».

Поэтому физическое хранение атрибута «наименование кни­га» оставим в таблице «Каталог», а для таблиц «Заказ», «Прода­жа» и «Автор» — создадим виртуальное поле подстановки этого атрибута. Атрибут <цсна одного экземпляра книги» сохраним в таблице «Каталог», для таблиц «Заказ» и «Продажа» создадим виртуальное поле подстановки. Поле «количество» имеет разный смысл: в таблице «Заказ» указано желаемое количество экземп­ляров книги, а таблица «Продажа» содержит количество опла­ченных экземпляров книги. Аналогичные рассуждения можно провести и для поля «сумма заказа», но это поле содержит резуль­тат умножения значения поля «количество» на значение поля «Цена одного экземпляра книги*. Поэтому поле «сумма заказа» будет виртуальным (вычисляемым) полем. Атрибут «способ оп­латы сохраним в таблице «Заказ», а для таблицы «Продажа* это поле оформим как виртуальное поле подстановки. При замене физических полей на виртуальные поля надо в таблицы ввести внешние ключи для связи с родительской таблицей (откуда бу­дем брать значение для подстановки).

Поле «Фамилия, имя и отчество автора» (покупателя, продав-

представителя заказчика и т. д.) разделим на три поля: фами- _ля^я»^Имя» отчество. Аналогично поле «адрес» разделим на два по-

• город, улица и оставшаяся часть адреса Поэтому создадим

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

Таблица 1.2.

Таблица	Ключ	Пале
Фамилия	Первичный	номер фамилии фамилия
Имя	Первичный	номер имени имя
Отчество	Первичный	номер отчества отчество
Город	Первичный	номер города наименование города телефонный код города
Улица	Первичный	номер улицы название улицы округ (район)

Условия первой нормальной формы выполнены, и база дан­ных состоит из 12таблиц: Клиент (Customer), Заказ (Order), Счет (Account), Продажа (Sale), Продавец (Salesman), Каталог (Catalog), Автор (Author), Фамилия (Fam), Имя (Im), Отчество (Ot), Город (Town) и Улица (Street). (Таблицы 1.1 и 1.2 — вспомо- ] гательные, в базу данных они не входят.)

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

Условия второй нормальной формы:

• выполняются условия первой нормальной формы;

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

• все поля зависят от первичного ключа;

• первичный ключ не должен быть избыточным.

Так как мы специально ввели первичные ключи, состоящие из одного поля, то избыточности первичного ключа быть не мо-

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

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

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

Условия третьей нормальной формы:

• выполняются условия второй нормальной формы;

• каждое не ключевое поле не должно зависеть от другого не ключевого поля.

Фор*^{ЛЯ ВССХ та}®^лиц выполняются условия третьей нормальной

На пятом этапе проектирования баз данных описывается

Ждая таблица. Каждой таблице присваивается имя, каждому

^лю присваивается имя, определяется тип и размер каждого

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

Таблица «Заказ»

Имя Тип Размер Ключ Назначение Примечание

поля поля поля

Keyorder Num 3 Первичный Уникальный

номер заказа

Key_cust Num 3 Внешний Порядковый

номер клиента

Keysalmn Num 3 Внешний Порядковый

номер продавца

Key_book Num 3 Внешний Порядковый

номер книги

Key_acnt Num 3 Внешний Порядковый

номер счета

Volume Num 4 Количество

экземпляров

книги

Num 5.2

Ргос

Торговая скидка

Summa_zakaz Сумма заказа

Виртуальное

вычисляемое

Рис. 1.13. Описание таблицы «Заказ».