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

Здравствуйте гость!

Задание № 2177

Наменование:

Курсовик Разработка программного обеспечения в среде СУБД FOXPRO

Предмет:

Базы данных

Бюджет:

0 руб.

Дата:

27.01.2011

Описание:

План выполнения курсовой работы
1.Изучение и описание предметной области

2.Построение концептуальной (инфологической ) модели

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

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

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


Содержание работы
Курсовая работа содержит следующие разделы:
• постановка задачи и разработка бизнес-правил;
• проектирование базы данных;
• разработка программного приложения для сопровождения базы данных;
• приложения;
• список литературы.

1. Постановка задачи и разработка бизнес-правил
Начальным этапом проектирования баз данных в конкретной предметной области является исследование и описание информационных потоков, которые существуют в рассматриваемой реальной системе и представляют интерес для разработчика автоматизированной системы управления данными. Результатом изучения предметной области является постановка задачи на разработку автоматизированной системы.
В постановке задачи обязательно должны быть отражены следующие положения:
• наименование задачи;
• цель разработки;
• бизнес-правила;
• требования к программе и оснащению;
• перечень вводимой информации;
• перечень печатных отчетов.
Например, фирма «Фронтон» занимается продажей легковых автомобилей на заказ. Процесс продажи проистекает следующим образом. Покупатель производит заказ на покупку автомобиля, пользуясь предоставленным ему фирмой каталогом легковых автомобилей. Представитель фирмы выписывает счет на выбранную модель автомобиля и одновременно с этим отправляет запрос о приобретении данного автомобиля заводу-изготовителю (фирме-поставщику). Фирма «Фронтон» заключила юридические соглашения о поставке автомобилей с рядом заводов-изготовителей легковых автомобилей и крупных дистрибьюторов. После оплаты по соответствующему счету фирма «Фронтон» подтверждает запрос о приобретении и обязуется в течение четырехнедельного периода предоставить покупку соответствующему покупателю.
В максимально простом виде схема бизнес-процесса фирмы «Фронтон» представлена на рис. 1.1. На основании исследований рынка потенциальных покупателей и предложений автоиндустрии служба или отдельный специалист разрабатывает каталог предлагаемых к продаже автомобилей; в большой фирме такую службу назвали бы отделом маркетинга. Каталог распространяется на рынке потенциальных покупателей. С клиентом, решившим приобрести автомобиль, работает служба оформления заказов. Специалисты, входящие в эту службу, принимают заказ, уточняют комплектацию выбранного автомобиля, отправляют счета, следят за их оплатой и, наконец, вручают клиенту поступивший автомобиль. Служба внутренней поддержки обеспечивает распределение работы по исполнителям и решает возникающие проблемы, например, ограничения доступа к данным.
При анализе бизнес-процесса фирмы полезно ответить на 6 вопросов: что, как, где, кто, когда и почему.

Рис.1.1 Упрощенная схема бизнес-процесса

При ответе на первый вопрос: «Что лежит в основе бизнеса данной фирмы?», как правило, выявляются наиболее важные для данного бизнеса или производственного процесса компоненты. В нашем случае это будут:
• сотрудники;
• клиенты (покупатели);
• поставщики;
• каталог;
• автомобили;
• заказы.
Ответ на второй вопрос: «Как это делается?» позволяет получить список основных бизнес-процессов, происходящих в фирме. Для нашего примера в такой список можно включить следующие пункты:
• составление каталога;
• рассылка каталога;
• анализ рынка;
• продажи;
• оформление счетов и накладных;
• управление работой персонала;
• реклама;
• решение бухгалтерских задач.
Вопрос «Где происходят данные процессы?» больше относится к проблемам телекоммуникаций и организации совместной работы персонала. Ведь в случае, например, большого объема операций, которые выполняются вне территории фирмы торговыми агентами, придется учитывать проблемы синхронизации данных. При наличии филиалов весьма непростой проблемой является оптимальный выбор системы распределения данных. Можно централизовать всю обработку данных, и филиалы будут выполнять свои операции, пользуясь возможностями телекоммуникаций. Работа с данными в этом случае упрощается, но каково будет удивление клиента, когда вы ему сообщите, что не можете взять у него несколько десятков тысяч долларов и продать приглянувшуюся машину, так как оборвалась связь с центральным офисом. В рассматриваемом примере допустим, что все операции выполняются в пределах одного здания, а организация совместного использования данных основана на возможностях локальной сети и сервера БД.
Ответ на вопрос «Кто выполняет эти процессы?» даст организационная структура фирмы. Упрощенная организационная структура фирмы «Фронтон» представлена на рис. 1.2.

Рис.1.2 Организационная структура фирмы

Важно получить и ответ на вопрос «Когда выполняется то или иное действие?». Это прояснит периодичность осуществляемых бизнес-процессов и позволит правильно расставить акценты в будущей прикладной программе. В нашем случае примем такую временную последовательность выполняемых процессов:
• обновление каталога – раз в год и внесение поправок в экстренных случаях;
• подведение итогов продаж – ежемесячно;
• годовой отчет – ежегодно к 20 февраля.
Последний вопрос «Почему эти действия выполняются?» позволяет определить мотивацию производственной деятельности фирмы. Бизнес-задачи фирмы «Фронтон» определим так:
• достижение наилучшего соотношения «затраты – удобство» для клиентов;
• обеспечение условий для успешной деятельности персонала;
• получение приемлемой прибыли;
• повышение доходов при автоматизации обработки данных.
Ответы на шесть перечисленных вопросов позволяют подойти к главному в постановке задачи – построении информационной модели предприятия.
Максимально формализованное описание задачи в нашем примере будет выглядеть следующим образом.

Наименование задачи:
Автоматизация управления работой дилера по продаже легковых автомобилей «AUTO STORE».

Цель работы дилера:
Продажа легковых автомобилей на заказ по каталогу.
Функции дилера:
• Заключение договоров на поставку автомобилей.
• Ведение каталога автомобилей, предлагаемых на продажу.
• Прием заказов у клиентов (покупателей) на поставку автомобилей.
• Работа с клиентами (маркетинг): реклама новых автомобилей, подготовка сведений о приобретаемых автомобилях, анализ продаж, ведение справочника клиентов.
• Отправка заказов поставщику автомобилей.
• Ведение расчетов за проданные автомобили (выписка накладных).
• Учет валютного курса.
Бизнес-правила:
• Сведения о клиентах хранятся 10 лет.
• Оплата ожидается 3 недели, если ее не происходит, заказ уничтожается.
• Подтверждение запроса о приобретении автомобиля отправляется фирме-поставщику после прихода денег.
• При отказе от поставленного автомобиля с покупателя удерживается 9% суммы оплаты по счету, данная величина должна регулироваться.
• Срок поставки 4 недели после прихода денег.
• Просрочка доставки автомобиля клиенту оплачивается фирмой «Фронтон» из расчета 0,1% в день, данная величина должна регулироваться.
• Если автомобиль не поставлен в течение 2 месяцев, возвращается вся сумма оплаты и пеня.

Требования к программе:
Программа должна работать под управлением операционных систем Windows 95 или Windows NT.

Перечень вводимой информации:
• наименование модели продаваемого автомобиля;
• рабочий объем двигателя, см3;
• количество цилиндров в двигателе;
• номинальная мощность двигателя, л.с.;
• максимальный крутящий момент, Н х м;
• максимальная скорость автомобиля, км/ч;
• время разгона автомобиля до 100 км/ч, с;
• количество дверей;
• количество мест;
• длина, мм;
• ширина, мм;
• высота, мм;
• расход топлива при скорости 90 км/ч, л/100 км;
• расход топлива при скорости 120 км/ч, л/100 км;
• расход топлива при городском цикле, л/100 км;
• наименование производителя автомобиля;
• наименование страны, в которой производится автомобиль;
• наименование используемого автомобилем топлива;
• наименование шин;
• наименование типа кузова;
• дата выпуска автомобиля;
• стоимость автомобиля;
• наименование клиента;
• адрес клиента;
• телефон клиента;
• факс клиента;
• фамилия, имя и отчество клиента;
• признак юридического лица клиента;
• примечание для записи заметок по работе с клиентом;
• номер счета;
• дата продажи;
• сумма продажи;
• пометка об оплате;
• фамилия, имя и отчество продавца.

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

Требования к оснащению офиса фирмы компьютерной техникой:
• Для пользователей: ПЭВМ не ниже Pentium 100/16/420 с операционной системой Windows 95 или Windows NT Workstation и пакетом программ MS Office.
• Сервер не ниже Pentium 166/32/1000 с операционной системой Windows NT Server и MS SQL Server 6.x.
• Локальная сеть.
• Сетевой лазерный или струйный принтер.

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

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

Концептуальное проектирование базы данных.
Этап 1.
Создание концептуальной модели данных исходя из представлений о предметной области.
1.1 Определение сущностей.
1.2 Определение типов связей.
1.3 Определение атрибутов и связывание их с типами сущностей и связей.
1.4 Определение доменов атрибутов.
1.5 Определение атрибутов, являющихся потенциальными и первичными ключами.
1.6 Специализация и генерализация типов сущностей (необязательный этап).
1.7 Создание диаграммы «сущность – связь».

Логическое проектирование базы данных.
Этап 2.
Построение и проверка логической модели данных на основе представлений о предметной области.
2.1 Определение набора отношений исходя из концептуальной модели данных.
2.2 Проверка модели с помощью правил нормализации.
2.3 Проверка модели в отношении транзакций пользователей.
2.4 Определение требований поддержки целостности данных.
Физическое проектирование базы данных с использованием реляционной СУБД.
Этап 3.
Перенос логической модели данных в среду реляционной СУБД.
3.1 Проектирование основных таблиц в среде СУБД.
3.2 Реализация ссылочной целостности в среде СУБД.

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

Данный этап проектирования базы данных состоит в разработке концептуальной модели данных исходя из представлений пользователя о предметной области создаваемого приложения. Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания. Обычно представление пользователя отражает некоторую функциональную область в общем поле деятельности предприятия – например, производство, маркетинг, сбыт, управление кадрами или складской учет. Пользователь может быть как отдельным работником, так и группой лиц, которые будут непосредственно работать с создаваемым приложением. В альтернативном случае понятие «пользователь» может представлять генерируемый системой отчет или даже запрос, связанный с получением результатов транзакции. Суть в том, что в любом случае выполнение требуемых пользователю действий должно обеспечиваться создаваемой системой.
Определить характеристики представлений пользователей можно с помощью различных методов. Начать следует с изучения диаграмм потоков данных, которые к этому моменту уже должны быть созданы. Изучение этих диаграмм позволит установить функциональные области и, возможно, отдельные функции. Затем рекомендуется провести опросы потенциальных пользователей, изучить деловые процедуры, существующие отчеты и формы и / или провести обследование работы предприятия.
Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. В области продажи автомобилей примерами объектов могут служить МОДЕЛЬ АВТОМОБИЛЯ, КЛИЕНТ и СЧЕТ.
Концептуальная модель данных включает следующее:
 типы сущностей;
 типы связей;
 атрибуты;
 домены атрибутов;
 потенциальные ключи;
 первичные ключи.
Концептуальная модель данных дополняется документацией, создаваемой в процессе разработки этой модели.

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

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

Сущность Описание сущности
Модель Данные о модели автомобиля.
Автомобиль Информация о типе и марке автомобиля.
Клиент Сведения о клиенте.
Продавец Данные о продавце.
Заказ Характеристика заказа.
Продажа Сведения о проданных автомобилях.
Счет Информация об оплате.
Этап 1.2. Определение типов связей.

После выделения сущностей следующим этапом разработки будет установление всех существующих между ними связей.
Связь – это функциональная зависимость между сущностями.
Тип связи – осмысленная ассоциация между сущностями разных типов.
При определении существующих связей из спецификаций на проект выбираются все выражения, в которых содержатся глаголы. Например:
 Фирма имеет персонал.
 Персонал занимается продажами автомобилей.
 Продавец принимает заказ.
Связи могут быть представлены следующими основными характеристиками:
 показатель кардинальности;
 степень участия (класс принадлежности).
Показатель кардинальности – описывает количество возможных связей для каждой из сущностей-участниц. Наиболее распространенными являются связи с показателями кардинальности «один к одному» (1:1), «один ко многим» (1:М) и «многие ко многим» (M:N). Если известны конкретные значения кардинальности или хотя бы верхний или нижний предел этих значений, то эту информацию обязательно нужно зафиксировать в документации.
Степень участия (класс принадлежности) – определяет, зависит ли существование некоторой сущности от участия в связи некоторой другой сущности. Существует 2 варианта участия сущности в связи:
 обязательное (тотальное, полное) – для существования некоторой сущности требуется существование другой сущности, связанной с ней определенной связью;
 необязательное (частичное) – для существования некоторой сущности не требуется существование другой сущности, связанной с ней определенной связью.
Модель, включающая сведения о кардинальности связей и степени участия в ней сущностей, более наглядно отражает смысл установленных связей. Кроме того, кардинальность связи и степень участия в ней сущностей представляют собой определенные ограничения, используемые для проверки и поддержания качества данных в базе. Эти ограничения являются теми утверждениями о свойствах экземпляров сущностей, которые могут быть проверены при изменении данных в базе с целью определения того, вызовут ли данные изменения нарушение установленных правил.
В большинстве случаев связи являются парными – другими словами, связи существуют только между двумя сущностями. Однако следует проявлять осторожность и тщательно проверять наличие в проекте комплексных связей, объединяющих более двух сущностей различных типов, а также рекурсивных связей, существующих между связями одного и того же типа.
Особое внимание следует уделять проверке того, были ли выделены все связи, явно или неявно присутствующие в спецификациях на проект.

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

Рассмотрим взаимосвязи между сущностями, включенными в информационную модель бизнес-процесса фирмы «Фронтон» (табл. 2.2).

Таблица 2.2
Взаимосвязи между сущностями

Сущность Связь Сущность
Клиент Делает Заказ
Клиент Оплачивает Счет
Заказ Определяет Модель
Продавец Принимает Заказ
Автомобиль Имеет Модель
Счет Включает Автомобиль
Счет Подтверждает Продажа

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

1) Клиент делает Заказ.
Один клиент в разное время может производить несколько заказов. Один заказ принадлежит только одному клиенту и поэтому между сущностями КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь «один ко многим».
Классы принадлежности сущностей КЛИЕНТ и ЗАКАЗ являются обязательными, так как каждый клиент должен сделать хотя бы один заказ, а любой заказ обязательно делается каким-либо клиентом.
2) Клиент оплачивает Счет.
Клиент может в случае приобретения нескольких автомобилей оплатить несколько счетов, но каждый счет может быть оплачен только одним клиентом. Значит, взаимосвязь между сущностями КЛИЕНТ и СЧЕТ определяется как «один ко многим».
Каждый клиент оплачивает хотя бы один счет, а каждый счет обязательно должен быть оплачен клиентом. Поэтому степени участия в данной связи сущностей КЛИЕНТ и СЧЕТ являются обязательными.

3) Заказ определяет Модель.
Каждая модель автомобиля может быть указана в нескольких заказах, а в любом заказе обязательно должна быть определена хотя бы одна модель. Следовательно, тип связи между сущностями МОДЕЛЬ и ЗАКАЗ – «один ко многим».
В любом заказе каждая модель автомобиля может быть либо указана, либо нет, но в каждом заказе обязательно должна быть определена модель автомобиля. Из этого следует, что класс принадлежности сущности ЗАКАЗ является обязательным, а сущности МОДЕЛЬ – необязательным.

4) Продавец принимает Заказ.
Продавец может принять несколько заказов, но каждый заказ должен быть оформлен одним продавцом. Поэтому связь между сущностями ПРОДАВЕЦ и ЗАКАЗ имеет тип «один ко многим».
Степень участия сущности ПРОДАВЕЦ является необязательной, так как возможна ситуация, когда данный продавец только поступил на работу в данную фирму и ещё не принял ни одного заказа. В то же время каждый заказ обязательно должен быть принят продавцом, что предусматривает обязательную степень участия сущности ЗАКАЗ.

5) Автомобиль имеет Модель.
В заказе на приобретение нескольких автомобилей должна быть указана модель каждого из них. Все автомобили могут быть одной модели. В этом случае взаимосвязью между сущностями МОДЕЛЬ и АВТОМОБИЛЬ является связь «один ко многим».
Каждый автомобиль обязательно имеет определенную модель, а каждая модель должна быть представлена хотя бы одним автомобилем. Следовательно, классы принадлежности обеих сущностей являются обязательными.

6) Счет включает Автомобиль.
О продаже каждого автомобиля свидетельствует счет. Может быть предъявлено несколько счетов на оплату покупки автомобилей одного типа. Между сущностями АВТОМОБИЛЬ и СЧЕТ можно установить связь «один ко многим».
Степени участия данных сущностей являются обязательными, так как на каждый проданный автомобиль выписывается отдельный счет, а каждый счет свидетельствует о продаже определенного автомобиля.
7) Счет подтверждает Продажа.
Каждая продажа подразумевает оформление одного или нескольких счетов. Следовательно, между сущностями ПРОДАЖА и СЧЕТ существует связь «один ко многим».
Продажу автомобиля подтверждает выписанный и оплаченный счет. Любой счет не может быть выписан без факта продажи. Поэтому степени участия сущностей СЧЕТ и ПРОДАЖА являются обязательными.


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

На данном этапе необходимо выявить все данные, описывающие сущности и связи, выделенные в создаваемой модели базы данных. Воспользуемся тем же методом, который применялся нами для идентификации сущностей: выберем все существительные и содержащие их фразы, присутствующие в спецификациях на проект. Выбранное существительное представляет атрибут в том случае, если оно описывает свойство, качество или характеристику некоторой сущности или связи.
Самый простой метод выделения атрибутов – после идентификации очередной сущности или связи в некоторой спецификации задать себе следующий вопрос: «Какую информацию требуется хранить о…». Ответ на этот вопрос надо искать в тексте спецификации.
Атрибуты делятся на простые и составные, однозначные и многозначные, а также производные.
Простым является атрибут, состоящий из одного компонента с независимым существованием. Простые атрибуты не могут быть разделены на более мелкие компоненты (например, атрибут пола). Простые атрибуты иногда называют атомарными. Составным называется атрибут, если он состоит из нескольких компонентов, каждый из которых характеризуется независимым существованием. Например, атрибут «Адрес» может быть простым и представлять все элементы адреса как единое значение: «Почтовая, 29; Жовтневый район; Луганск, 91000». В другом варианте этот же атрибут может быть представлен как составной, т.е. состоящий из серии простых атрибутов, содержащих различные элементы адреса. В этом случае то же самое значение может быть разделено на такие атрибуты, как «Улица» (Почтовая, 29), «Район» (Жовтневый), «Город» (Луганск) и «Почтовый индекс» (91000). Выбор способа представления адреса в виде простого или составного атрибута определяется требованиями, предъявляемыми к приложению пользователем. Если пользователь не нуждается в доступе к отдельным элементам адреса, то его целесообразно представить как простой атрибут. Но если пользователю требуется независимый доступ к отдельным элементам адреса, то атрибут «Адрес» следует сделать составным, образованным из необходимого количества простых атрибутов.
Однозначный атрибут содержит одно значение для одной сущности (например, фамилия клиента). Большинство атрибутов типов сущностей являются однозначными для каждого отдельного экземпляра этой сущности. Многозначным является атрибут, который содержит несколько значений для одной сущности. Многозначный атрибут допускает присутствие определенного количества значений (возможно, в заданных пределах – максимальном и минимальном количестве). В качестве примера можно привести номер телефона клиента. Если клиентом является юридическое лицо (предприятие), то каждый его отдел имеет свой номер телефона. Предположим, что атрибут «Телефон» сущности КЛИЕНТ может иметь от 1 до 10 значений.
Атрибуты, значения которых могут быть установлены с помощью значений других атрибутов, называются производными, или вычисляемыми. Например, производными атрибутами являются:
 возраст работника;
 общая сумма продаж фирмы на конкретную дату;
 количество автомобилей, которые были проданы за определенный период времени.
Очень часто подобные атрибуты вообще не отображаются в концептуальной модели данных. Однако в некоторых случаях может иметь место риск удаления или модификации атрибута или атрибутов, значения которых используются для вычисления значения производного атрибута. В этом случае производный атрибут должен быть представлен в модели данных, что позволит предупредить нежелательную потерю информации. Однако если производный атрибут показан в модели данных, следует непременно указать, что он является именно производным. Способ представления производных атрибутов устанавливается на этапе физического проектирования базы данных. В зависимости от того, как данный реквизит применяется, новое значение производного реквизита может вычисляться либо при каждом обращении к нему, либо только при изменении значений атрибутов, используемых для его расчета.
При определении используемых в некотором приложении атрибутов очень часто оказывается, что на предыдущих этапах одна или более сущностей были пропущены. В этом случае следует вернуться к уже выполненным этапам и документально оформить вновь обнаруженные сущности, после чего проанализировать связи, в которых они принимают участие.
Может оказаться полезным подготовить список всех атрибутов, используемых в спецификациях на проект. По мере связывания очередного атрибута с некоторой сущностью или связью, он вычеркивается из списка. Подобный метод позволяет гарантировать, что каждый из атрибутов будет связан с сущностью или связью только одного типа. Когда из списка будет вычеркнут последний атрибут, все идентифицированные в модели атрибуты окажутся связанными с некоторой сущностью или связью.

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

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


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

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

Примерами доменов атрибутов являются:
 Домен атрибута, включающий допустимые номера заказов. Он состоит из трехсимвольных строк, в которых первый символ является буквой, а остальные два – цифрами, задающими числа в диапазоне 1-99.
 Домен атрибута, включающий допустимые значения номеров телефонов и факсов. Он состоит из строк длиной в 13 цифровых символов.
 Допустимыми значениями для атрибута «Пол» сущности ПРОДАВЕЦ являются «М» и «Ж». Домен этого атрибута состоит из двух строк длиной в один символ, имеющих указанные значения.

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

Список доменов атрибутов для рассматриваемой задачи приведен в табл.2.3.



Таблица 2.3
Домены атрибутов

Название Описание
Integer Положительные целые числа
Char Символьные выражения
Real Действительные числа
Date Дата в формате ДД.ММ.ГГ
Pol Две строки длиной в один символ, имеющие значения «М» и «Ж»


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

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

Атрибуты, включаемые в состав БД для модели, описанной выше, приведены в табл. 2.4.
Таблица 2.4
Атрибуты сущностей и домены атрибутов

Сущность Атрибуты Домен атрибута
МОДЕЛЬ Уникальный ключ модели
Наименование модели
Наименование фирмы
Наименование страны
Рабочий объем двигателя
Количество цилиндров
Мощность
Крутящий момент
Наименование топлива
Максимальная скорость
Время разгона до 100 км/ч
Наименование шин
Наименование кузова
Количество дверей
Количество мест
Длина
Ширина
Высота
Расход топлива при 90 км/ч
Расход топлива при 120 км/ч
Расход топлива при городском цикле Integer
Char
Char
Char
Integer
Integer
Real
Real
Char
Real
Real
Char
Char
Integer
Integer
Integer
Integer
Integer
Real
Real
Real
АВТОМОБИЛЬ Уникальный ключ автомобиля
Уникальный ключ модели
Дата выпуска
Стоимость Integer
Integer
Date
Real
КЛИЕНТ Уникальный ключ клиента
Наименование клиента
Адрес
Телефон
Факс
Фамилия
Имя
Отчество
Признак юридического лица
Примечание Integer
Char
Char
Integer
Integer
Char
Char
Char
Char
Char
ПРОДАЖА Счет
Дата продажи
Сумма Integer
Date
Real
СЧЕТ Номер записи
Счет
Уникальный счет клиента
Уникальный счет автомобиля
Дата выписки
Пометка об оплате
Сумма Integer
Integer
Integer
Integer
Date
Char
Real
ЗАКАЗ Уникальный ключ заказа
Уникальный ключ клиента
Уникальный ключ модели
Уникальный счет продавца Integer
Integer
Integer
Integer
ПРОДАВЕЦ Уникальный ключ продавца
Фамилия
Имя
Отчество Integer
Char
Char
Char

* Для каждой сущности подчеркнутый атрибут является первичным ключом.


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

На этом этапе при необходимости можно продолжить разработку концептуальной модели, используя процедуры специализации или генерализации по отношению к сущностям, выделенным на этапе 1.1. При проведении специализации предпринимается попытка выделить различия – путем определения одного или более подклассов некоторой сущности, которая в этом случае называется суперклассом специализации. При проведении генерализации предпринимается попытка выделить общие свойства некоторых сущностей – путем определения обобщающей сущности, называемой суперклассом генерализации.
Нет никаких четких рекомендаций по поводу того, в каких случаях ER-модель следует дополнительно расширять с помощью механизмов специализации и генерализации. В каждом отдельном случае принимаемое решение будет чисто субъективным и должно приниматься с учетом конкретных особенностей моделируемой предметной области.
Для оценки целесообразности применения специализации и генерализации следует попытаться, используя эти процедуры, представить на ER-модели важнейшие сущности и их связи. Степень специализации или генерализации объектов ER-диаграммы определяется, прежде всего, общей читабельностью этой диаграммы и той ясностью, с которой на ней моделируются важнейшие типы сущностей и связей приложения.
Для примера, описанного выше, нет необходимости проводить специализацию и генерализацию типов сущностей, так как все выделенные сущности в достаточной мере конкретизированы и соответствуют описанию и постановке задачи.
Специализацию и генерализацию типов сущностей рассмотрим на следующем примере. Предположим, в результате анализа бизнес-процесса фирмы выделена сущность РАБОТНИК. В зависимости от функций, выполняемых каждым работником, можно выделить подклассы данной сущности – НАЧАЛЬНИК ОТДЕЛА, МЕНЕДЖЕР, ПРОДАВЕЦ. Их атрибуты характеризуют функции, выполняемые различными работниками. В данном случае сущность РАБОТНИК является суперклассом специализации.
Допустим, выделены сущности ПРОДАВЕЦ, БУХГАЛТЕР, МЕНЕДЖЕР. Для каждой из них характерен определенный набор атрибутов («фамилия», «имя», «отчество», «адрес», «телефон», «дата рождения», «зарплата»). Целесообразно повторяющиеся атрибуты выделить в отдельную сущность, например, РАБОТНИК, называемую суперклассом генерализации, а атрибутами сущностей ПРОДАВЕЦ, БУХГАЛТЕР, МЕНЕДЖЕР описать специфические свойства данных сущностей, если таковые имеются.


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

На данном этапе создаётся ER-диаграмма, отображающая концептуальную модель данных, которая характеризует представления пользователей о предметной области приложения.
ER-диаграмма концептуальной модели бизнес-процесса фирмы «Фронтон» приведена на рис. 2.5.














– обязательная степень участия сущности в связи,
– необязательная степень участия сущности в связи

Рис. 2.5 ER-диаграмма концептуальной модели бизнес-процесса фирмы «Фронтон»
Этап 2.
Построение и проверка логической модели данных на основе представлений о предметной области.
На данном этапе мы продолжим работу с концептуальной моделью данных, созданной на предыдущем этапе. Задача состоит в доработке этой модели с целью удаления из неё всех элементов, затрудняющих реализацию данных моделей в среде реляционных СУБД. В результате выполнения этих действий структура концептуальной модели данных будет изменена таким образом, чтобы полностью отвечать требованиям, выдвигаемым реляционной моделью организации баз данных. Поэтому новую модель более корректно называть логической моделью данных. Далее созданная логическая модель данных будет проверена с использованием правил нормализации и подвергнута контролю на возможность выполнения всех необходимых пользователям транзакций так, как это указано в спецификациях на создаваемое приложение. Впоследствии проверенная логическая модель данных можно будет использовать как прототип, если это потребуется.


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

На данном этапе следует на основе созданной ER-диаграммы определить наборы отношений (таблиц), необходимые для представления сущностей и связей.
Проектирование базы данных из ER-диаграмм
При проектировании базы данных из ER-диаграммы следует соблюдать следующие правила:
 Если между сущностями связь «один к одному» и классы принадлежности обеих сущностей являются обязательными, то для реализации требуется только одна таблица. Её первичным ключом может быть ключ одной из сущностей.
 Если между сущностями связь «один к одному» и класс принадлежности одной из сущностей является обязательным, а другой – нет, то необходимо построение двух таблиц, т.е. под каждую сущность надо выделить по одной таблице. При этом первичный ключ сущности должен служить первичным ключом для соответствующей таблицы. Кроме того, ключ сущности с необязательным классом принадлежности добавляется в качестве атрибута в таблицу, выделенную для сущности с обязательным классом принадлежности.
 Если между сущностями связь «один к одному» и классы принадлежности обеих сущностей являются необязательными, то необходимо создать три таблицы: по одной для каждой сущности, ключи которых служат первичными ключами для соответствующих таблиц, и одну таблицу для связи. Среди своих атрибутов таблица, выделяемая для связи, должна иметь по одному ключу от каждой сущности.
 Если между сущностями связь «один ко многим» и класс принадлежности n-связанной сущности является обязательным, то достаточно использовать две таблицы (по одной на каждую сущность) при условии, что ключ односвязной сущности должен быть добавлен как атрибут в таблицу, выделенную для n-связанной сущности.
 Если между сущностями связь «один ко многим» и класс принадлежности n-связанной сущности является необязательным, то для реализации данной ER-диаграммы необходимо создать три таблицы: по одной для каждой сущности, при этом первичные ключи сущностей являются ключами для соответствующих таблиц, и одну таблицу для связи, которая должна иметь среди своих атрибутов ключи для двух других таблиц.
 Если между сущностями связь «многие ко многим», то независимо от их классов принадлежности необходимо выделить три таблицы: по одной для каждой сущности, первичные ключи которых являются ключами соответствующих таблиц, и одну таблицу для связи, в которую входят первичные ключи двух таблиц.

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

1.

Таблицы:
«Продавец» (Уникальный ключ продавца, …*);
«Заказ» (Уникальный ключ заказа, Уникальный ключ продавца, …).

2.

Таблицы:
«Клиент» (Уникальный ключ клиента, …);
«Заказ» (Уникальный ключ заказа, Уникальный ключ клиента,…).

3.

Таблицы:
«Модель» (Уникальный ключ модели, …).
«Заказ» (Уникальный ключ заказа, Уникальный ключ модели …);

4.


Таблицы:
«Клиент» (Уникальный ключ клиента, …);
«Счет» (Номер записи, Уникальный ключ клиента,…).

5.


Таблицы:
«Модель» (Уникальный ключ модели, …);
«Автомобиль» (Уникальный ключ автомобиля, Уникальный ключ модели, ).

6.


Таблицы:
«Автомобиль» (Уникальный ключ автомобиля, …);
«Счет» (Номер записи, Уникальный ключ автомобиля, …).

7.


Таблицы:
«Продажа» (Счет, …);
«Счет» (Номер записи, Счет, …).

* … – поля таблиц аналогичны атрибутам сущностей (см. табл. 2.4)

Таким образом, на данном этапе база данных «AUTO STORE» представлена 7 таблицами (табл. 2.6).
Таблица 2.6
Список таблиц

Таблица Первичный ключ Внешние ключи
Автомобиль Уникальный ключ автомобиля Уникальный ключ модели
Заказ Уникальный ключ заказа Уникальный ключ клиента
Уникальный ключ модели
Уникальный ключ продавца
Клиент Уникальный ключ клиента –
Модель Уникальный ключ модели –
Продавец Уникальный ключ продавца –
Продажа Счет –
Счет Номер записи Уникальный ключ автомобиля
Уникальный ключ клиента
Счет



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

Нормализация используется для улучшения модели данных, для того чтобы она удовлетворяла различным ограничениям, позволяющим исключить нежелательное дублирование данных. Нормализация гарантирует, что полученная в результате её применения модель данных будет наилучшим образом отображать особенности использования информации на предприятии, не содержать противоречий, иметь минимальную избыточность и максимальную устойчивость.
Приведение модели к требуемому уровню нормальной формы является основой построения реляционной БД.
В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи. Теория нормализации основана на том, что определенный набор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем все остальные наборы таблиц, с помощью которых могут быть представлены те же данные. Введение нормализации отношений при разработке информационной модели обеспечивает минимальный объем физической, то есть записанной на каком-либо носителе, БД и ее максимальное быстродействие, что впрямую отражается на качестве функционирования информационной системы.
Нормализация информационной модели включает следующие этапы:
 приведение к первой нормальной форме (1НФ), позволяющее удалить из отношений повторяющиеся группы атрибутов;
 приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;
 приведение к третьей нормальной форме (3НФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа;
 приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии.
Целью выполнения этих этапов является получение гарантий того, что каждое из отношений, созданных на основании логической модели данных, отвечает, по крайней мере, требованиям НФБК. Если будут найдены отношения, не отвечающие требованиям НФБК, это может указывать на то, что часть логической модели данных неверна либо преобразование логической модели в набор отношений выполнено некорректно. При необходимости требуется перестроить модель данных и убедиться, что она верно отображает моделируемую часть информационной структуры предприятия.
Данные, представленные в виде двумерной таблицы, являются первой нормальной формой реляционной модели данных.
Первый этап нормализации заключается в образовании двумерной таблицы, содержащей все необходимые атрибуты информационной модели, и в выделении ключевых атрибутов. Очевидно, что полученная весьма внушительная таблица будет содержать очень разнородную информацию. В этом случае будут наблюдаться аномалии включения, обновления и удаления данных, так как при выполнении этих действий нам придется уделить внимание данным (вводить или заботиться о том, чтобы они не были стерты), которые не имеют к текущим действиям никакого отношения. Например, может наблюдаться такая парадоксальная ситуация. При включении в каталог продаж новой модели автомобиля нам сразу придется указать купившего ее клиента.
Отношение задано во второй нормальной форме, если оно является отношением в первой нормальной форме и каждый атрибут, не являющийся первичным атрибутом в этом отношении, полностью зависит от любого возможного ключа этого отношения.
Если все возможные ключи отношения содержат по одному атрибуту, то это отношение задано во второй нормальной форме, так как в этом случае все атрибуты, не являющиеся первичными, полностью зависят от возможных ключей. Если ключи состоят более чем из одного атрибута, отношение, заданное в первой нормальной форме, может не быть отношением во второй нормальной форме. Приведение отношений ко второй нормальной форме заключается в обеспечении полной функциональной зависимости всех атрибутов от ключа за счет разбиения таблицы на несколько таблиц, в которых все имеющиеся атрибуты будут иметь полную функциональную зависимость от ключа этой таблицы. В процессе приведения модели ко второй нормальной форме в основном исключаются аномалии дублирования данных.
Отношение задано в третьей нормальной форме, если оно задано во второй нормальной форме и каждый атрибут этого отношения, не являющийся первичным, не транзитивно зависит от каждого возможного ключа этого отношения.
Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С — три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А, как это схематично показано на рис. 2.7, a. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два, как это показано на рис. 2.7, б.
Например, если все данные о моделях автомобилей и самих поступающих автомобилях хранятся в одном отношении, то для нескольких автомобилей одной модели пришлось бы многократно указывать тип кузова, количество дверей и другие технические характеристики. В этом случае технические характеристики зависят от модели автомобиля и при наличии нескольких автомобилей одной модели будут дублироваться. Дублирование исчезает, если из одного отношения выделить отношение, в котором будут храниться данные о моделях, и отношение, в котором будут храниться данные об автомобилях.


Рис. 2.7 Пример транзитивной зависимости:
а) отношения между объектами с транзитивной зависимостью;
б) отношения между объектами без транзитивной зависимости

При проектировании базы данных необходимо следовать следующим основным правилам:
 Исключать повторяющиеся группы – для каждого набора связанных атрибутов создавать отдельную таблицу и снабжать ее первичным ключом. Выполнение этого правила автоматически приведет ко второй нормальной форме. Например, следует список клиентов поместить в отдельную таблицу, а в списке заказов использовать только присвоенные им уникальные идентификаторы.
 Исключать избыточные данные – перемещать атрибут в отдельную таблицу, если он зависит только от части составного ключа. Это правило помогает избежать потери одних данных при удалении каких-то других. Везде, где возможно использование идентификаторов вместо описания, необходимо выносить в отдельную таблицу список идентификаторов с пояснениями к ним.
 Исключать столбцы, которые не зависят от ключа – перемещать атрибуты в отдельную таблицу, если они не вносят свою лепту в описание ключа.
В процессе нормализации стало ясно, что концептуальная модель базы данных «AUTO STORE» должна быть расширена с помощью механизма специализации. Поэтому следует видоизменить список атрибутов сущности МОДЕЛЬ и добавить такие новые сущности, как ТОПЛИВО, ШИНЫ, КУЗОВ, ФИРМА, СТРАНА. Между сущностью МОДЕЛЬ и сущностями ТОПЛИВО, ШИНЫ, КУЗОВ, ФИРМА следует установить связь «один ко многим», так как
одни и те же виды топлива, шин и кузова могут быть использованы в различных моделях, и каждая фирма может производить несколько моделей. Классы принадлежности данных сущностей являются обязательными (рис. 2.8). Несколько фирм могут представлять одну страну, поэтому связь между сущностями СТРАНА и ФИРМА имеет кардинальность «один ко многим», а степени участия данных сущностей также являются обязательными (рис.2.9).












Рис. 2.8 Специализация сущности МОДЕЛЬ на этапе нормализации





Рис. 2.9 Связь между сущностями ФИРМА и СТРАНА

На основе данных ER-диаграмм (рис. 2.8 и 2.9) можно дополнительно выделить следующие отношения.

а)



Таблицы:
«Топливо» (Уникальный ключ топлива, …)*;
«Модель» (Уникальный ключ модели, Уникальный ключ топлива, …).


б)


Таблицы:
«Шины» (Уникальный ключ шин, …);
«Модель» (Уникальный ключ модели, Уникальный ключ шин, …).

в)


Таблицы:
«Кузов» (Уникальный ключ кузова, …);
«Модель» (Уникальный ключ модели, Уникальный ключ кузова, …).

г)


Таблицы:
«Фирма» (Уникальный ключ фирмы, …);
«Модель» (Уникальный ключ модели, Уникальный ключ фирмы, …).

д)


Таблицы:
«Страна» (Уникальный ключ страны, …);
«Фирма» (Уникальный ключ фирмы, Уникальный ключ страны,…).

* – поля данных таблиц аналогичны атрибутам измененных или добавленных сущностей (см. табл. 2.10)

В основном изменения в модели связаны с введением искусственных атрибутов, которые в виде кодов участвуют в отношениях вместо естественных атрибутов (вид топлива, марка шин и т. п.), К необходимости введения в модель искусственных атрибутов мы пришли в процессе нормализации. В общем случае коды рекомендуется использовать вместо естественных атрибутов в следующих случаях:
 В предметной области может наблюдаться синонимия, то есть естественный атрибут отношения не обладает свойством уникальности. Например, среди сотрудников фирмы могут быть однофамильцы или даже полные тезки. В этом случае решить проблему помогает уникальный табельный номер.
 Если отношение участвует во многих связях, то для их отображения создается несколько таблиц, в каждой из которых повторяется идентификатор отношения. Для того чтобы не использовать во всех таблицах длинный естественный атрибут объекта, можно применять более короткий код. Это также будет способствовать повышению быстродействия вашей системы.
 Если естественный атрибут может изменяться во времени (например, фамилия), то это может вызвать очень большие сложности при эксплуатации системы. Например, девушка-продавец вышла замуж. Что будет с данными, которые привязаны к ее девичьей фамилии? Использование неизменяемого кода (табельного номера) позволит избежать этих сложностей.
Таблица 2.10
Атрибуты и домены атрибутов измененных или добавленных сущностей

Сущность Атрибуты Домен атрибута
МОДЕЛЬ Уникальный ключ модели
Наименование модели
Уникальный ключ фирмы
Рабочий объем двигателя
Количество цилиндров
Мощность
Крутящий момент
Уникальный ключ топлива
Максимальная скорость
Время разгона до 100 км/ч
Уникальный ключ шин
Уникальный ключ кузова
Количество дверей
Количество мест
Длина
Ширина
Высота
Расход топлива при 90 км / ч
Расход топлива при 120 км / ч
Расход топлива при городском цикле Integer
Char
Integer
Integer
Integer
Real
Real
Integer
Real
Real
Integer
Integer
Integer
Integer
Integer
Integer
Integer
Real
Real
Real
ТОПЛИВО Уникальный ключ топлива
Наименование топлива Integer
Char
ШИНЫ Уникальный ключ шин
Наименование шин Integer
Char
КУЗОВ Уникальный ключ кузова
Наименование кузова Integer
Char
ФИРМА Уникальный ключ фирмы
Наименование фирмы
Уникальный ключ страны Integer
Char
Integer
СТРАНА Уникальный ключ страны
Наименование страны Integer
Char

В результате проверки модели с помощью правил нормализации получим окончательный вид ER-диаграммы проектируемой базы данных (рис. 2.11).
Таблицы, соответствующие сущностям, выделенным на этапе нормализации, должны быть внесены в общий список таблиц (табл. 2.12).





















Рис. 2.11 ER-диаграмма базы данных «AUTO STORE» после нормализации

Таблица 2.12
Список таблиц после нормализации модели данных

Таблица Первичный ключ Внешние ключи
Автомобиль Уникальный ключ автомобиля Уникальный ключ модели
Заказ Уникальный ключ заказа Уникальный ключ клиента
Уникальный ключ модели
Уникальный ключ продавца
Клиент Уникальный ключ клиента –
Кузов Уникальный ключ кузова –
Модель Уникальный ключ модели Уникальный ключ кузова
Уникальный ключ шин
Уникальный ключ топлива
Уникальный ключ фирмы
Продавец Уникальный ключ продавца –
Продажа Счет –
Страна Уникальный ключ страны –
Счет Номер записи Уникальный ключ автомобиля
Уникальный ключ клиента
Счет
Топливо Уникальный ключ топлива –
Фирма Уникальный ключ фирмы Уникальный ключ страны
Шины Уникальный ключ шин –

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

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

Печатный отчет Используемые таблицы
Номенклатура автомобилей, предлагаемых к продаже Автомобиль
Кузов
Модель
Страна
Топливо
Фирма
Шины
Список клиентов Клиент
Анализ продаж Продажа
Счет
Список заказов Заказ
Клиент
Модель
Продавец
Счет на покупку Автомобиль
Клиент
Продажа
Счет


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

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

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

Ограничения для атрибутов (полей)

Для полей могут использоваться следующие виды ограничений:
 Тип и формат поля автоматически допускают ввод только данных определенного типа. Выбор типа поля Date в формате ДД.ММ.ГГ позволит пользователю ввести только шесть чисел. При этом первая пара цифр не сможет превысить в лучшем случае значения 31, а вторая – 12.
 Задание диапазона значений, как правило, используется для числовых полей. Диапазон допустимых значений может быть ограничен с двух сторон (закрытый диапазон), а может с какой-то одной: верхней или нижней (открытый диапазон).
 Недопустимость пустого поля позволяет избежать появления в базе данных «ничейных» записей, в которых пропущены какие-либо обязательные атрибуты.
 Задание списка значений позволяет избежать излишнего разнообразия данных, если его можно ограничить. Например, для указания типа кузова следует использовать только общепринятые названия: Седан, кабриолет и т.д.
 Проверка на уникальность значения какого-то поля позволяет избежать записей-дубликатов. Вряд ли будет удобно в справочнике клиентов иметь несколько записей для одного и того же лица

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

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

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

Ссылочная целостность
Внешний ключ связывает каждую строку дочернего отношения с той строкой родительского отношения, которая содержит это же значение соответствующего потенциального ключа. Понятие ссылочной целостности означает, что если внешний ключ содержит некоторое значение, то оно обязательно должно присутствовать в потенциальном ключе одной из строк родительского отношения.
Существует несколько важных моментов, связанных с использованием внешних ключей. Во-первых, следует проанализировать, допустимо ли использование во внешних ключах пустых значений. В общем случае, если степень участия дочернего отношения в связи является обязательной, то рекомендуется запрещать использование пустых значений в соответствующем внешнем ключе. В то же время, если степень участия дочернего отношения в связи является необязательной, то помещение пустых значений в атрибут внешнего ключа должно быть разрешено.
Реализация поддержки ссылочной целостности осуществляется посредством задания ограничений существования, определяющих условия, при которых может вставляться, обновляться или удаляться каждое значение потенциального или внешнего ключа. Рассмотрим связь «Клиент делает Заказ» типа 1:M. Первичный ключ отношения «Клиент» – атрибут «Уникальный ключ клиента» – является внешним ключом отношения «Заказ». Рассмотрим следующие ситуации.
Случай 1. Вставка новой строки в дочернее отношение («Заказ»). Для обеспечения ссылочной целостности необходимо убедиться, что значение атрибута внешнего ключа «Уникальный ключ клиента» новой строки отношения «Заказ» равно пустому значению либо некоторому конкретному значению, присутствующему в одной из строк отношения «Клиент».
Случай 2. Удаление строки из дочернего отношения («Заказ»). При удалении строки из дочернего отношения никаких нарушений ссылочной целостности не происходит.
Случай 3. Обновление внешнего ключа в строке дочернего отношения («Заказ»). Этот случай подобен случаю 1. Для сохранения ссылочной целостности необходимо убедиться, что атрибут «Уникальный ключ клиента» в обновленной строке отношения «Заказ» содержит либо пустое значение, либо некоторое конкретное значение, присутствующее в одной из строк отношения «Клиент».
Случай 4. Вставка строки в родительское отношение («Клиент»). Вставка строки в родительское отношение («Клиент») не может вызвать нарушения ссылочной целостности. Добавленная строка просто становится родительским объектом, не имеющим дочерних объектов.
Случай 5. Удаление строки из родительского отношения («Клиент»). При удалении строки из родительского отношения ссылочная целостность будет нарушена в том случае, если в дочернем отношении будут существовать строки, ссылающиеся на удаленную строку родительского отношения. Другими словами, ссылочная целостность будет нарушена, если удаленный клиент сделал один или более заказов. В этом случае может быть использована одна из следующих стратегий.
 RESTRICT. Удаление строки из родительского отношения запрещается, если в дочернем отношении существует хотя бы одна ссылающаяся на нее строка. В нашем случае это означает: «Нельзя удалить сведения о клиенте, сделавшем до настоящего момента хотя бы один заказ».
 CASCADE. При удалении строки из родительского отношения автоматически удаляются все ссылающиеся на нее строки дочернего отношения. Если любая из удаляемых строк дочернего отношения выступает в качестве родительской стороны в некоторой другой связи, то операция удаления применяется ко всем строкам дочернего отношения этой связи и т.д. Другими словами, удаление строки родительского отношения автоматически распространяется на любые дочерние отношения. В нашем случае это значит: «Удаление клиента автоматически влечет за собой удаление сведений обо всех сделанных им заказах».
 SET NULL. При удалении строки из родительского отношения во всех ссылающихся на нее строках дочернего отношения в атрибут внешнего ключа записывается пустое значение. Следовательно, удаление строк из родительского отношения вызовет занесение пустого значения в соответствующий атрибут строк дочернего отношения. В нашем случае это звучит так: «При удалении клиента все сделанные им заказы остаются без человека, который их сделал». Эта стратегия может использоваться только в тех случаях, когда в атрибут внешнего ключа дочернего отношения разрешается помещать пустые значения.
 SET DEFAULT. При удалении строки из родительского отношения в атрибут внешнего ключа всех ссылающихся на нее строк дочернего отношения автоматически помещается значение, указанное для этого атрибута как значение по умолчанию. Таким образом, удаление строки из родительского отношения вызывает помещение принимаемого по умолчанию значения в атрибут внешнего ключа всех строк дочернего отношения, ссылающихся на удаленную строку. Эта стратегия применима только в тех случаях, когда атрибуту внешнего ключа дочернего отношения назначено некоторое значение, принимаемое по умолчанию.
 IGNORE. При удалении строки из родительского отношения никаких действий по сохранению ссылочной целостности данных не предпринимается.
Случай 6. Обновление первичного ключа в строке родительского отношения («Клиент»). Если значение первичного ключа некоторой строки родительского отношения будет обновлено, нарушение ссылочной целостности будет иметь место в том случае, если в дочернем отношении существуют строки, ссылающиеся на исходное значение первичного ключа. В нашем случае это значит, что клиент, для которого было выполнено обновление, в данный момент сделал один или более заказов. Для сохранения ссылочной целостности может использоваться любая из описанных выше стратегий. При использовании стратегии CASCADE обновление значения первичного ключа в строке родительского отношения будет отображено в любой строке дочернего отношения, ссылающейся на данную строку (каскадным образом).

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


Этап 3.
Перенос логической модели данных в среду реляционной СУБД.

Этап 3.1. Проектирование основных таблиц в среде СУБД.
Базовыми для базы данных «AUTO STORE» являются следующие таблицы:
 Model – «Модель»;
 Firm – «Фирма»;
 Country – «Страна»;
 Fuel_oil – «Топливо»;
 Tyre – «Шины»;
 Body – «Кузов»;
 Automobile – «Автомобиль»;
 Customer – «Клиент»;
 Sale – «Продажа»;
 Account_ – «Счет»;
 Order – «Заказ»;
 Salesman – «Продавец».

Таблица 2.13
Физическая организация базы данных «AUTO STORE»

Наименование
поля Тип поля Коли-
чество
симво
лов Тип
индекса Примечание
Model (Модель)
Key_model Integer 5 Primary Уникальный ключ модели
Name_model Character 20 Наименование модели
Key_firm Integer 5 Regular Уникальный ключ фирмы
Swept_volume Integer 3 Рабочий объем двигателя, см3
Quantity_drum Integer 2 Количество цилиндров
Capacity Numeric 5 Мощность, л. с.
Torgue Numeric 5 Крутящий момент
Key_fuel_oil Integer 5 Regular Уникальный ключ топлива
Top_speed Numeric 5 Максимальная скорость, км / ч
Starting Numeric 5 Время разгона до 100 км/ч, с
Key_tyre Integer 5 Regular Уникальный ключ шин
Key_body Integer 5 Regular Уникальный ключ кузова
Quantity_door Integer 3 Количество дверей
Quantity_sead Integer 3 Количество мест
Length Integer 5 Длина, мм
Width Integer 5 Ширина, мм
Height Integer 5 Высота, мм
Expense_90 Numeric 5 Расход топлива при 90 км/ч,
л / 100 км
Expense_120 Numeric 5 Расход топлива при 120 км/ч,
л / 100 км
Expense_town Numeric 5 Расход топлива при городском цикле, л / 100 км
Firm (Фирма)
Key_firm Integer 5 Primary Уникальный ключ фирмы
Name_firm Character 20 Наименование фирмы
Key_country Integer 5 Regular Уникальный ключ страны
Country (Страна)
Key_country Integer 5 Primary Уникальный ключ страны
Name_country Character 20 Наименование страны
Fuel_oil (Топливо)
Key_fuel_oil Integer 5 Primary Уникальный ключ топлива
Name_fuel_oil Character 20 Наименование топлива
Tyre (Шины)
Key_tyre Integer 5 Primary Уникальный ключ шин
Name_tyre Character 20 Наименование шин

Таблица 2.13
(продолжение)
Body (Кузов)
Key_body Integer 5 Primary Уникальный ключ кузова
Name_body Character 20 Наименование кузова
Automobile (Автомобиль)
Key_auto Integer 5 Primary Уникальный ключ автомобиля
Key_model Integer 5 Regular Уникальный ключ модели
Date_issue Date 10 Дата выпуска в формате ДД.ММ.ГГ
Cost Numeric 10 Стоимость, $
Customer
Key_customer Integer 5 Primary Уникальный ключ клиента
Name_customer Character 30 Наименование клиента
Address Character 30 Адрес
Tel Integer 10 Телефон
Fax Integer 10 Факс
Last_name Character 20 Фамилия
First_name Character 20 Имя
Patronymic Character 20 Отчество
Juridicial Character 1 Признак юридического лица
Comment Character 30 Примечание
Sale (Продажа)
Account Integer 5 Primary Счет
Date_sale Date

Предложения исполнителей

30.01.2011

Имя и адрес пользователя:

Колесников Евгений jk-81@mail.ru

Сумма:

3000 руб.

Срок выполнения:

2 дня

Текст предложения:

Готов выполнить вашу работу, пишите на jk-81@mail.ru