MySQL. Библиотека профессионала - Аткинсон Л

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

В этой главе...

Спецификация требований Спецификация проекта Составление схемы базы данных Реализация модели Тестирование Планирование жизненного цикла

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

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

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

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

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

Спецификация требований

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

84 Глава 7. Проектирование баз данных

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

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

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

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

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

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

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

1)должно быть описано только внешнее поведение системы;

2)должны быть определены ограничения реализации;

3)спецификация должна легко модифицироваться;

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

5)должен быть заранее описан цикл функционирования системы;

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

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

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

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

Спецификация требований должна быть документом, который поможет будущему программисту познакомиться с возможностями системы. Не удивляйтесь, если через полгода таким программистом окажетесь вы сами. И не допустите, чтобы данное ка чество спецификации вступило в конфликт с предыдущим качеством: простотой мо дификации. Спецификация требований — это "визитная карточка" системы, но не ее основная документация.

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

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

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

Ниже перечислены девять рекомендуемых разделов спецификации:

1)обзор целей и задач системы;

2)среда функционирования и разработки;

3)внешние интерфейсы и потоки данных;

4)функциональныетребования;

5)требования к производительности;

6)обработка исключительных ситуаций;

7)приоритеты реализации;

8)возможные модификации;

9)проектные рекомендации.

86 Глава 7. Проектирование баз данных

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

Наша книга посвящена программе MySQL ибазам данных, но в полной программ ной системе всегда есть какие то подсистемы. W eb приложению требуется Web сервер, сервер приложений и Web броузер. Можно составить общую спецификацию всей системы или отдельно описать каждую подсистему, но позаботьтесь о том, чтобы база данных упоминалась в правильном контексте.

Знание среды функционирования помогает определить список внешних интер фейсов. MySQL работает по технологии "клиент/сервер". Клиенты подключаются по протоколам TCP/IP, через UNIX сокеты или именованные каналы. СУБД может соз давать на диске журнальные файлы и образы таблиц. Опишите потоки данных в сис теме. Лучше всего сделать это с помощью диаграмм.

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

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

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

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

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

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

Спецификация проекта

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

Ниже приведен перечень свойств, которыми должна обладать хорошая специфи кация проекта:

1)должно быть упомянуто каждое исходное требование;

2)должны быть определены возможные варианты реализации;

3)спецификация должна легко модифицироваться;

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

5)спецификация должна придерживаться простых решений;

6)связи между модулями должны быть слабыми.

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

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

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

Проектирование— это итерационный процесс, поэтому проектная спецификация должна быть такой, чтобы изменения было легко вносить. Разбейте документ на логи ческие разделы и пронумеруйте их. Существуют программы, предназначенные для по строения проектных диаграмм. Среди них отметим открытый пакет Dia(www.lysator.liu. se/alla/dia).

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

Хороший проект является простым. Простые проекты легче понять, следовательно, реализация получится более качественной. Чрезмерная сложность проекта обычно свидетельствует о преждевременных попытках оптимизировать систему. В контексте баз данных процесс оптимизации называется нормализацией (рассматривается в гла ве 8, "Нормализация").

88 Глава 7, Проектирование баз данных

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

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

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

Вспецификации проекта должны присутствовать четыре важных раздела:

1)стратегия;

2)архитектура;

3)правила;

4)детали проекта.

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

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

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

ипринципы тестирования.

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

Составление схемы базы данных

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

Существуют два основных типа диаграмм: диаграммы потоков данных и диаграм мы отношений объектов (entity relationship, ER). На примере первых демонстриру ются функциональные преобразования, претерпеваемые данными при переходе из

90Глава 7. Проектирование баз данных

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

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

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

Языки моделирования

Существует несколько стандартов моделирования информационных структур во обще и баз данных в частности. Среди них диаграммы Бейчмана, модель отношений объектов, стандарты IDEF1X и UML (Uniform Modeling Language — единый язык мо делирования). Диаграммы Бейчмана были разработаны Чарльзом Бейчманом для описания сетевых баз данных, но некоторые их идеи применимы и для реляционных баз данных. Модель отношений объектов впервые была описана Питером Ченом (Peter Chen) в 1976 г. под влияниемстатьи доктора Кодда, посвященной реляционной алгебре. Стандарт IDEF1X был принят правительством США в 1993 г. UML— это по пулярный язык моделирования, созданный Гради Бучем (Grady Booch), Айваром Якобсоном (Ivar Jacobson) и Джимом Рамбо (Jim Rumbaugh) из компании Rational Software Corporation.

Люди часто говорят "база данных", имея в виду "система управления реляционны ми базами данных". Это объясняется двумя причинами: удобством и тем, что реляци онная модель намного превосходит по популярности все остальные модели. Точно так же диаграммами отношений объектов стали называть любые диаграммы, в кото рых информационные сущности изображаются в виде замкнутых фигур, а отношения между ними обозначаются линиями. Строгое определение таких диаграмм было дано в исходной работе Чена под названием "Модель отношений объектов: попытка уни фицированного представления данных" ("The Entity Relationship Model: Toward a Unified View of Data").

Дополнительную информацию о стандарте IDEF1X можно получить на Web узле www.idef.com. Там выложен 145 страничный документ, содержащий описание методик составления диаграмм.

Компания Rational SoftwareведетWeb узел,посвященный языку UML (www.rational. com/umt). Стандарт UML основан на методологии объектно ориентированного про ектирования, позволяющей создавать многократно используемые программные ком поненты. Концепции многих моделей хорошо выражаются диаграммами UML. Прав да, считается, что традиционные диаграммы лучше подходят для описания информа ционных систем, в частности баз данных.