Горев А., Макашарипов С., Ахаян Р. Эффективная работа с СУБД

Подождите немного. Документ загружается.

1.2. Описание, постановка задачи и разработка бизнес-

правил

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

можем отметить, что в 77 случаях из 100 заказчик сам не знает, чего хочет, и в 99 из 100

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

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

очень часто, при очередном обсуждении с заказчиком возможностей новой системы, мы

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

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

вариант. Иной раз уже через несколько часов после прощального рукопожатия заказчик

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

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

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

основании чего самостоятельно сформулировать постановку задачи. Уверяем вас, если результат

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

нуждается в данной программе, а самое главное, знает чего хочет.

В этом параграфе мы попробуем уяснить, как должно выглядеть описание и постановка

задачи.

Некая фирма "Фронтон" (название придумали большие любители технологии клиент-сервер,

поэтому его надо читать на зарубежный манер: вдохните и скажите "фронт", сделайте задержку

дыхания и на выдохе произнесите "он") занимается продажей легковых автомобилей на заказ.

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

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

Представитель фирмы выписывает счет на выбранную модель автомобиля и одновременно с этим

отправляет запрос о приобретении данного автомобиля на завод-изготовитель (фирме -

поставщику). Фирма "Фронтон" заключила юридические соглашения о поставке автомобилей с

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

по соответствующему счету фирма "Фронтон" подтверждает запрос о приобретении и обязуется в

течение четырехнедельного периода предоставить покупку соответствующему покупателю.

В максимально простом виде схема бизнес-процесса фирмы "Фронтон" представлена на рис.

1.4. На основании исследований рынка потенциальных покупателей и предложений

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

продаже автомобилей; в большой фирме такую службу назвали бы отделом маркетинга. Каталог

распространяется на рынке потенциальных покупателей. С клиентом, решившим приобрести

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

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

их оплатой и наконец вручают клиенту поступивший автомобиль. Служба внутренней поддержки

обеспечивает распределение работы по исполнителям и решает возникающие проблемы,

например, ограничения доступа к данным.

При анализе бизнес-процесса фирмы полезно ответить на 6 вопросов: что, как, где, кто, когда

и почему.

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

converted to PDF by HupBaH9I

При ответе на первый вопрос: "Что лежит в основе бизнеса данной фирмы?", как правило,

выявляются наиболее важные для данного бизнеса или производственного процесса компоненты.

В нашем случае это будут:

• cотрудники;

• клиенты (покупатели);

• поставщики;

• каталог;

• автомобили;

• заказы.

Ответы на второй вопрос: "Как это делается?" позволяют получить список основных бизнес-

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

следующие пункты:

• составление каталога;

• рассылка каталога;

• анализ рынка;

• продажи;

• оформление счетов и накладных;

• управление работой персонала;

• реклама;

• решение бухгалтерских задач.

Вопрос: "Где происходят данные процессы?" больше относится к проблемам

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

большого объема операций, которые выполняются вне территории фирмы торговыми агентами,

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

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

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

телекоммуникаций. Работа с данными в этом случае упрощается, но каково будет удивление

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

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

рассматриваемом примере допустим, что все операции выполняются в пределах одного здания, а

организация совместного использования данных основана на возможностях локальной сети и

сервера БД.

Ответ на вопрос: "Кто выполняет эти процессы?" даст организационная структура фирмы.

Упрощенная организационная структура фирмы "Фронтон" представлена на рис. 1.5.

Рис. 1.5.

Важно получить и ответ на вопрос: "Когда выполняется то или иное действие?" Это прояснит

периодичность осуществляемых бизнес-процессов и позволит правильно расставить акценты в

converted to PDF by HupBaH9I

будущей прикладной программе. В нашем случае примем такую временную последовательность

выполняемых процессов:

• обновление каталога - раз в год и внесение поправок в экстренных случаях;

• подведение итогов продаж - ежемесячно;

• годовой отчет - ежегодно к 20 февраля.

Последний вопрос: "Почему эти действия выполняются?" позволяет определить мотивацию

производственной деятельности фирмы. Бизнес-задачи фирмы "Фронтон" определим так:

• достижение наилучшего соотношения "затраты - удобство" для клиентов;

• обеспечение условий для успешной деятельности персонала;

• получение приемлемой прибыли;

• повышение доходов при автоматизации обработки данных.

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

- построении информационной модели предприятия. В простейшем виде такая модель может быть

отображена в виде взаимосвязей между бизнес-компонентами и бизнес-процессами, как это

показано на рис. 1.6. В практике проектирования информационных систем такие схемы получили

название ER-диаграмм (Entity-relationship diagram (ERD) - диаграмма "Сущность-связь"). ER-

диаграммы хорошо вписываются в методологию структурного анализа и проектирования

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

проектируемой системы, которое начинается с ее общего обзора и затем уточняется, давая

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

Рис. 1.6. Диаграмма взаимосвязей между бизнес-компонентами и бизнес-процессами

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

следующим образом.

Наименование задачи:

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

Цель работы дилера:

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

Функции дилера:

• Заключение договоров на поставку автомобилей.

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

• Прием заказов у клиентов (покупателей) на поставку автомобилей.

• Работа с клиентами (маркетинг): реклама новых автомобилей, подготовка сведений о

приобретаемых автомобилях, анализ продаж, ведение справочника клиентов.

• Отправка заказов поставщику автомобилей.

• Ведение расчетов за проданные автомобили (выписка накладных).

• Учет валютного курса.

Бизнес-правила:

• Сведения о клиентах хранятся 10 лет.

• Оплата ожидается 3 недели, если ее не происходит, заказ уничтожается.

converted to PDF by HupBaH9I

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

после прихода денег.

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

счету, данная величина должна регулироваться.

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

• Просрочка доставки автомобиля клиенту оплачивается фирмой "Фронтон" из расчета

0,1% в день, данная величина должна регулироваться.

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

пеня.

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

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

NT.

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

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

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

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

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

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

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

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

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

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

• длина, мм;

• ширина, мм;

• высота, мм;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• номер счета;

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

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

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

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

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

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

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

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

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

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

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

converted to PDF by HupBaH9I

• Для пользователей: ПЭВМ не ниже Pentium 100/16/420 с операционной системой Windows

95 или Windows NT Workstation и пакетом программ MS Office.

• Сервер не ниже Pentium 166/32/1000 с операционной системой Windows NT Server и MS

SQL Server 6.х.

• Локальная сеть.

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

Глава 2

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

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

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

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

Типы моделей данных

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

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

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

Этап 3. Задание первичных и альтернативных ключей, определение атрибутов сущностей

Этап 4. Приведение модели к требуемому уровню нормальной формы

Этап 5. Физическое описание модели

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

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

Если вам удалось осмыслить задачу, поставленную перед вами заказчиком, примерно так, как

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

настала пора воплощать задуманное в "материализованном" виде. Необходимо потратить еще

немного усилий для приведения полученной от заказчика информации к наиболее подходящему

виду.

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

При проектировании системы обработки данных именно данные и интересуют нас в первую

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

данных призвана информационная модель.

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

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

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

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

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

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

объектами.

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

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

требований ряда пользователей (рис. 2.1). Концептуальные требования могут определяться и для

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

может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все

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

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

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

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

физического хранения.

converted to PDF by HupBaH9I

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

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

в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения

особенностей реализации и вопросов эффективности обработки. Проектирование

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

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

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

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

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

Концептуальная модель транслируется затем в модель данных, совместимую с выбранной

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

окажутся впоследствии нереализуемыми средствами выбранной СУБД. Это потребует изменения

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

конкретной СУБД, называется логической моделью.

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

содержания и среде хранения.

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

Пользователям выделяются подмножества этой логической модели, называемые внешними

моделями (в некоторых источниках их также называют подсхемами), отражающие их

представления о предметной области. Внешняя модель соответствует представлениям, которые

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

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

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

физическую память, такую, как диск, лента или какой-либо другой носитель информации.

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

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

Внешние модели никак не связаны с типом физической памяти, в которой будут храниться

данные, и с методами доступа к этим данным. Это положение отражает первый уровень

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

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

оказывать влияния на существующие внешние модели. Это - второй уровень независимости

данных. Уровни независимости данных показаны на рис. 2.1. Важно помнить, что построение

логической модели обусловлено требованиями используемой СУБД. Поэтому при замене СУБД

она также может измениться.

С точки зрения прикладного программирования независимость данных определяется не

техникой программирования, а его дисциплиной. Например, для того чтобы при любом

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

константы (постоянные значения данных) в программе. Лучшее решение состоит в передаче

программе значений в качестве параметров.

Все актуальные требования предметной области и адекватные им "скрытые" требования на

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

нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в

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

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

использования данных для получения информации.

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

Всесторонний анализ объектов предметной области и их взаимосвязей минимизирует влияние

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

всеобъемлющая независимость данных.

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

логической и физической) состоит в способах представления взаимосвязей между объектами.

При проектировании БД нам потребуется различать взаимосвязи между объектами, между

атрибутами одного объекта и между атрибутами различных объектов.

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

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

взаимосвязи типа "один к одному", "один ко многим" и "многие ко многим".

converted to PDF by HupBaH9I

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

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

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

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

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

(уникальный ключ клиента). Информация о каждом клиенте включает наименование клиента,

адрес, телефон, факс, фамилию, имя, отчество, признак юридического лица и примечание. Таким

образом, атрибутами объекта КЛИЕНТ являются "УНИКАЛЬНЫЙ КЛЮЧ КЛИЕНТА",

"НАИМЕНОВАНИЕ КЛИЕНТА", "АДРЕС КЛИЕНТА" и т. д.

Следующий представляющий для нас интерес объект - МОДЕЛЬ АВТОМОБИЛЯ. Этот объект

имеет атрибуты "УНИКАЛЬНЫЙ КЛЮЧ МОДЕЛИ", "НАИМЕНОВАНИЕ МОДЕЛИ" и т. д.

Третий рассматриваемый объект - ЗАКАЗ. Его атрибутами являются "НОМЕР ЗАКАЗА", "КЛЮЧ

КЛИЕНТА" и "КЛЮЧ МОДЕЛИ".

И четвертый рассматриваемый объект - ПРОДАВЕЦ. Его атрибутами являются "УНИКАЛЬНЫЙ

КЛЮЧ ПРОДАВЦА", "ИМЯ ПРОДАВЦА", "ФАМИЛИЯ" и "ОТЧЕСТВО".

Взаимосвязь "один к одному" (между двумя типами объектов)

Мысленно вернемся к временам планово-распределительной экономики. Допустим, в

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

между объектами КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь "один к одному", обозначаемая

одинарными стрелками, как это показано на рис. 2.2,а.

Между данными, хранящимися в объектах КЛИЕНТ и ЗАКАЗ, будет существовать взаимосвязь,

в которой каждая запись в одном объекте будет однозначно указывать на запись в другом

объекте. На рис. 2.3 приведен пример такой взаимосвязи между данными. Ни в одном, ни в

другом объекте не может существовать записи, не связанной с какой-либо записью в другом

объекте.

Рис. 2.3. Взаимосвязь между данными при отношении "один к одному"

Взаимосвязь "один ко многим" (между двумя типами объектов)

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

автомобилей, при этом несколько клиентов не могут являться обладателями одного автомобиля.

Взаимосвязь "один ко многим" можно обозначить с помощью одинарной стрелки в направлении к

"одному" и двойной стрелки в направлении ко "многим", как это показано на рис. 2.2,б.

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

основным) будет соответствовать несколько записей второго объекта (дочернего или

подчиненного). Взаимосвязь "один ко многим" очень распространена при разработке

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

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

качестве такого справочника можно представить объект КЛИЕНТ, в котором хранятся сведения о

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

converted to PDF by HupBaH9I

покупок, которые он сделал и сведения о которых хранятся в объекте МОДЕЛЬ АВТОМОБИЛЯ,

как это показано на рис. 2.4. В случае, если в дочернем объекте будут какие-то записи, для

которых нет соответствующих записей в объекте КЛИЕНТ, то мы их не увидим. В этом случае

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

вы узнаете, как избегать подобных ситуаций.

Рис. 2.4. Взаимосвязь между данными при отношении "один ко многим"

Если мы будем просматривать записи объекта МОДЕЛЬ АВТОМОБИЛЯ, то в объекте КЛИЕНТ мы

сможем получить данные о клиенте, купившем данный автомобиль (см. рис. 2.4). Обратите

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

Взаимосвязь "многие ко многим" (между двумя типами объектов)

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

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

обслужен различными продавцами. Между объектами КЛИЕНТ и ПРОДАВЕЦ существует

взаимосвязь "многие ко многим". Такая взаимосвязь обозначается двойными стрелками, как это

показано на рис. 2.2,в. На рис. 2.5 приведена схема, по которой в этом случае будут

взаимосвязаны данные. При просмотре данных в объекте КЛИЕНТ мы сможем узнать, какие

продавцы обслуживали определенного клиента. Однако в объекте ПРОДАВЕЦ в этом случае нам

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

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

серьезными проблемами. Например, не сможем ввести в объект ПРОДАВЕЦ уникальный ключ для

каждого продавца, так как неизбежно один продавец будет обслуживать нескольких клиентов, и

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

converted to PDF by HupBaH9I

Рис. 2.5. Взаимосвязь между данными при отношении "многие ко многим"

Согласно теории реляционных баз данных для хранения взаимосвязи "многие ко многим"

требуются три объекта: по одному для каждой сущности и один для хранения связей между ними

(промежуточный объект). Промежуточный объект будет содержать идентификаторы связанных

объектов, как это показано на рис. 2.6.

converted to PDF by HupBaH9I

Рис. 2.6.

Взаимосвязи между объектами являются частью концептуальной модели и должны

отображаться в базе данных.

Наряду с взаимосвязями между объектами существуют взаимосвязи между атрибутами

объекта. Здесь также различают взаимосвязи типа "один к одному", "один ко многим" и "многие

ко многим".

Взаимосвязь "один к одному" (между двумя атрибутами)

Мы предполагаем, что ключ (номер) клиента является его уникальным идентификатором, то

есть он не изменяется и при последующих поступлениях заказов от данного клиента. Если

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

(например, номер паспорта), то между такими двумя уникальными идентификаторами существует

взаимосвязь "один к одному". На рис. 2.7,а эта взаимосвязь обозначается одинарными

стрелками.

Взаимосвязь "один ко многим" (между двумя атрибутами)

Имя клиента и его номер существуют совместно. Клиентов с одинаковыми именами может быть

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

Это означает, что данному номеру клиента соответствует только одно имя. Взаимосвязь "один ко

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

направлении ко "многим" (рис. 2.7,б).

Взаимосвязь "многие ко многим" (между двумя атрибутами)

Несколько клиентов с одинаковыми именами могли быть обслужены несколькими продавцами.

Несколько продавцов с одинаковыми именами могли полу-чить заказы от нескольких клиентов.

converted to PDF by HupBaH9I