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

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

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

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

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

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

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

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

Определение объема и типов данных

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

ру базы данных.

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

или заменой. В таких ситуациях стоит изучить имеющиеся данные.

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

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

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

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

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

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

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

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

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

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

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

решать с помощью этих данных.

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

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

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

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

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

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

возможность доступа и модификации сведений о покупателях. Кроме iuu>. для раз.мс ас-ния заказов им требуется просматривать данные о складских запасах. В компании может быть и другая категория пользователей сотрудники отдела кадров. Им нужно право на

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

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

Определение бизнес-правил системы

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

баз данных SQL 3

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

Упражнение 2. Определение требований к структуре базы данных

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

файле.

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

Сценарий базы данных для книжного магазина

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

названия, автора, рекомендованной розничной цены и оценки состояния.

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

случа издания не может быть меньше 1600 и больше 2099 (последнее в соответствии с назначением новой СУБД).

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