лабы / gorev_akhajan_makakshiripov_ehffektivnaja_rabota_s_subd

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n.

Хранимые процедуры - это приложение (программа), объединяющее запросы и процедурную логику (операторы присваивания, логического ветвления и т. д.) и хранящееся в базе данных.

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

Правила позволяют вызывать выполнение заданных действий при изменении или добавлении данных в базу данных (БД) и тем самым контролировать истинность помещаемых в нее данных.

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

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

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

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

Обратите внимание на исключительную важность в этом определении слова "автоматически". Ни пользователь, ни приложение не могут активизировать триггер, он выполняется автоматически, когда пользователь или приложение выполняют с БД определенные действия. Триггер включает в себя следующие компоненты:

•Ограничения, для реализации которых собственно и создается триггер.

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

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

Использование триггеров при проектировании БД позволяет получить при разработке приложения следующие преимущества:

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

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

www.books-shop.com

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

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

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

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

•отсутствие проверки;

•проверка допустимости;

•запрет операции;

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

•установка пустого (NULL) значения или заданного значения по умолчанию.

Нормализация отношений - это процесс построения оптимальной структуры таблиц и связей в реляционной БД.

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

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

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

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

Занимаясь разработкой автоматизированных систем на протяжении длительного времени, мы можем отметить, что в 77 случаях из 100 заказчик сам не знает, чего хочет, и в 99 из 100 постановку задачи приходится воспринимать на слух, в процессе работы неоднократно уточняя те или иные мелкие, но значимые моменты будущего приложения. Более того, в таких случаях очень часто, при очередном обсуждении с заказчиком возможностей новой системы, мы открываем для себя все новые и новые горизонты предстоящей работы, требующие существенного расширения функциональности будущей программы. Но это не самый плохой вариант. Иной раз уже через несколько часов после прощального рукопожатия заказчик полностью переосмысливает свои цели, после чего задача в корне меняется, и следующий визит заставляет нас начать всю работу заново. Именно по этой причине мы рекомендуем вам, внимательно выслушав заказчика, попросить его описать задачу в письменном виде, на основании чего самостоятельно сформулировать постановку задачи. Уверяем вас, если результат окажется положительным, то это будет признанием того, что ваш заказчик действительно нуждается в данной программе, а самое главное, знает чего хочет.

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

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

www.books-shop.com

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

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

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

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

ипочему.

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

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

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

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

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

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

•каталог;

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

•заказы.

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

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

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

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

•продажи;

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

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

•реклама;

www.books-shop.com

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

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

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

Рис. 1.5.

Важно получить и ответ на вопрос: "Когда выполняется то или иное действие?" Это прояснит периодичность осуществляемых бизнес-процессов и позволит правильно расставить акценты в будущей прикладной программе. В нашем случае примем такую временную последовательность выполняемых процессов:

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

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

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

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

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

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

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

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

Ответы на шесть перечисленных вопросов позволяют подойти к главному в постановке задачи - построении информационной модели предприятия. В простейшем виде такая модель может быть отображена в виде взаимосвязей между бизнес-компонентами и бизнес-процессами, как это показано на рис. 1.6. В практике проектирования информационных систем такие схемы получили название ER-диаграмм (Entity-relationship diagram (ERD) - диаграмма "Сущность-связь"). ER-

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

www.books-shop.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

www.books-shop.com

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

•длина, мм;

•ширина, мм;

•высота, мм;

•расход топлива при скорости 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.х.

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

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

Глава 2

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

www.books-shop.com

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

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

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

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

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

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

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

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

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

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

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

В рассматриваемой задаче по автоматизации управления работой дилера по продаже легковых автомобилей, если клиент производит заказ на покупку автомобиля впервые, осуществляется первичная регистрация его данных и сведений о сделанном заказе. Если же клиент производит заказ повторно, осуществляется регистрация только данного заказа. Вне зависимости от того, сколько раз данный клиент производил заказы, он имеет уникальный идентификационный номер (уникальный ключ клиента). Информация о каждом клиенте включает наименование клиента, адрес, телефон, факс, фамилию, имя, отчество, признак юридического лица и примечание. Таким образом, атрибутами объекта КЛИЕНТ являются "УНИКАЛЬНЫЙ КЛЮЧ КЛИЕНТА", "НАИМЕНОВАНИЕ КЛИЕНТА", "АДРЕС КЛИЕНТА" и т. д.

Следующий представляющий для нас интерес объект - МОДЕЛЬ АВТОМОБИЛЯ. Этот объект имеет атрибуты "УНИКАЛЬНЫЙ КЛЮЧ МОДЕЛИ", "НАИМЕНОВАНИЕ МОДЕЛИ" и т. д.

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

www.books-shop.com

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

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

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

Мысленно вернемся к временам планово-распределительной экономики. Допустим, в определенный момент времени один клиент может сделать только один заказ. В этом случае между объектами КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь "один к одному", обозначаемая одинарными стрелками, как это показано на рис. 2.2,а.

Между данными, хранящимися в объектах КЛИЕНТ и ЗАКАЗ, будет существовать взаимосвязь, в которой каждая запись в одном объекте будет однозначно указывать на запись в другом объекте. На рис. 2.3 приведен пример такой взаимосвязи между данными. Ни в одном, ни в другом объекте не может существовать записи, не связанной с какой-либо записью в другом объекте.

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

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

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

Вэтом случае одной записи данных первого объекта (его часто называют родительским или основным) будет соответствовать несколько записей второго объекта (дочернего или подчиненного). Взаимосвязь "один ко многим" очень распространена при разработке реляционных баз данных. В качестве родительского объекта часто выступает справочник, а в дочернем хранятся уникальные ключи для доступа к записям справочника. В нашем примере в качестве такого справочника можно представить объект КЛИЕНТ, в котором хранятся сведения о всех клиентах. При обращении к записи для определенного клиента нам доступен список всех покупок, которые он сделал и сведения о которых хранятся в объекте МОДЕЛЬ АВТОМОБИЛЯ, как это показано на рис. 2.4. В случае, если в дочернем объекте будут какие-то записи, для которых нет соответствующих записей в объекте КЛИЕНТ, то мы их не увидим. В этом случае говорят, что объект содержит потерянные (одинокие) записи. Это не допустимо, и в дальнейшем вы узнаете, как избегать подобных ситуаций.

www.books-shop.com