Подтверждение запроса о приобретении автомобиля отправляется фирме-поставщику после прихода денег.

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

Срок поставки 4 недели после прихода денег.

Просрочка доставки автомобиля клиенту оплачивается фирмой Фронтон из расчета 0,1% в день, данная величина должна регулироваться.

Если автомобиль не поставлен в течение 2 месяцев, возвращается вся сумма оплаты и пеня.

Требования к программе:

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

Перечень вводимой информации:

наименование модели продаваемого автомобиля;

рабочий объем двигателя, cм 3;

количество цилиндров в двигателе;

номинальная мощность двигателя, л. с.;

максимальный крутящий момент, НФм;

максимальная скорость автомобиля, км/ч;

время разгона автомобиля до 100 км/ч, с;

количество дверей;

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

длина, мм;

ширина, мм;

высота, мм;

расход топлива при скорости 90 км/ч, л/100 км;

расход топлива при скорости 120 км/ч, л/100 км;

расход топлива при городском цикле, л/100 км;

наименование производителя автомобиля;

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

наименование используемого автомобилем топлива;

наименование шин;

наименование типа кузова;

дата выпуска автомобиля;

стоимость автомобиля;

наименование клиента ;

адрес клиента;

телефон клиента;

факс клиента;

фамилия, имя и отчество клиента;

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

примечание для записи заметок по работе с клиентом;

номер счета ;

дата продажи;

сумма продажи;

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

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

Перечень печатных отчетов:

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

список клиентов;

анализ продаж;

список заказов;

счет на покупку.

Требования к оснащению офиса фирмы компьютерной техникой:

Глава 2

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

2.1. Информационная модель данных

Последовательность создания информационной модели Взаимосвязи в модели Типы моделей данных

2.2. Проектирование базы данных

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

Этап 2. Определение взаимосвязей между сущностями

Этап 3. Задание первичных и альтернативных ключей, определение атрибутов сущностей Этап 4. Приведение модели к требуемому уровню нормальной формы Этап 5. Физическое описание модели

2.3. Словарь данных

2.4. Администрирование базы данных

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

виду.

2.1. Информационная модель данных

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

В этом параграфе мы познакомимся:

с общими принципами разработки информационной модели;

с отличиями между концептуальной, логической и физической моделями данных;

с различными видами взаимосвязей между элементами модели.

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

Последовательность создания информационной модели

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

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

Для пользователей: ПЭВМ не ниже Pentium 100/16/420 с операционной системой Windows 95 или Windows NT Workstation и пакетом программ MS Office.

Сервер не ниже Pentium 166/32/1000 с операционной системой Windows NT Server и MS SQL Server 6. х. Локальная сеть.

Сетевой лазерный или струйный принтер.

Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.

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

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

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

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

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

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

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

Взаимосвязи в модели

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

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

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