Взаимодействие заказчика базы данных с разработчиком
Общие замечания
Эта книга рассчитана не на программистов, а на экономистов и юристов. Она не ставит задач научить читателя созданию баз данных, но, тем не менее, мы рассмотрим, как они проектируются. Это необходимо, поскольку еще до создания базы данных чрезвычайно важно обеспечить грамотное взаимодействие между заказчиком и разработчиком. Они должны уметь разговаривать на одном языке, понимать потребности и возможности друг друга. Реалии современного мира таковы, что не существует предприятий и организаций, в которых не было бы практической целесообразности в применении технологий баз данных. Подходя с этих позиций, надо признать, что любой экономист или юрист рано или поздно будет выступать либо пользователем, либо заказчиком базы данных.
Все базы данных можно классифицировать согласно тому, как к ним подходит трудовой коллектив, на удобные и неудобные. Если внедрение базы данных на предприятии ничего не дает трудовому коллективу, кроме дополнительной нагрузки, он изыскивает способы парировать внедрение и саботировать производительную работу системы. Анализ многочисленных примеров «внедренных», но не работающих баз данных показывает, что ответственность за неудачу разделяют как разработчик, так и заказчик. То, что заказчик не является специалистом в области баз данных, не имеет никакого значения. Он является специалистом в своей предметной области и должен уметь объяснить свои потребности и задачи разработчику.
Для разработки проекта базы данных не нужны ни компьютер, ни знание технологии баз данных, ни умение программировать. Вполне достаточно представлять потребности своей организации, знать узкие места в делопроизводстве, представлять список документов, необходимых во внутреннем обороте и во внешней отчетности.
Методически правильно начинать работу с карандашом и листом бумаги в руках, не используя компьютер. На этапе проектирования он вообще не нужен. Неоптимальные решения и прямые ошибки, заложенные на этом этапе, впоследствии очень трудно устраняются, поэтому этот этап является основополагающим.
Разработка технического задания
Техническое задание на проектирование базы данных должен предоставить заказчик. Для этого он должен владеть соответствующей терминологией и знать, хотя бы в общих чертах, технические возможности основных систем управления базами данных. К сожалению, на практике такое положение встречается не всегда. Поэтому обычно используют следующие подходы:
• разработчик демонстрирует заказчику работу аналогичной базы данных, после чего заказчик высказывает свои пожелания и они согласовывают спецификацию отличий;
• если аналога нет, разработчик выясняет круг задач и потребностей заказчика, после чего помогает ему подготовить техническое задание.
При подготовке технического задания составляют:
• список исходных данных, с которыми работает заказчик;
• список выходных данных, которые необходимы заказчику для управления структурой своего предприятия;
• список выходных данных, которые заказчик должен предоставлять в другие организации (в вышестоящие структуры, в органы статистического учета, прочие административные и контролирующие организации).
При этом очень важно не ограничиваться взаимодействием с головным подразделением заказчика, а провести обследование всех служб и подразделений, которые могут оказаться поставщиками данных в базу или их потребителями. Так, например, при подготовке базы данных для учета абитуриентов и студентов в высшем учебном заведении, необходимо не только изучить документооборот ректората и всех деканатов, но и понять, что хотели бы получить от базы данных службы, распределяющие учебную нагрузку преподавателей, отвечающие за распределение аудиторного фонда, за проживание студентов в общежитии и другие. В расчет должны приниматься и такие службы, как библиотека, отдел кадров и прочие. В любой момент может выясниться, например, что администрация библиотеки должна периодически поставлять кому-то отчеты, характеризующие читательскую активность студентов в зависимости от пола, возраста и социального положения. К возможным пожеланиям заказчика следует готовиться на этапе проектирования, до создания базы.
Разработка схемы данных
Выяснив основную часть данных, которые заказчик потребляет или поставляет, можно приступать к созданию структуры базы, то есть, структуры ее основных таблиц.
1.Работа начинается с составления генерального списка полей — он может насчитывать сотни позиций.
2.В соответствии с тем, какие данные размещаются в каждом поле, определяют наиболее подходящий тип для каждого поля.
3.Далее распределяют поля генерального списка по базовым таблицам. На первом этапе распределение производят по функциональному признаку. Принцип разделения очень прост: обеспечить, чтобы ввод данных в одну таблицу производился в рамках одного подразделения, а еще лучше — на одном рабочем месте.
Наметив столько таблиц, сколько подразделений (рабочих мест) охватывает база данных, приступают к дальнейшему делению таблиц. Критерием необходимости деления является факт множественного повтора данных в соседних записях. На рис. 14.6 показана таблица, у которой в поле Адрес наблюдается повтор данных. Это явное свидетельство того, что таблицу надо поделить на две взаимосвязанных таблицы и, возможно, заполнять эти таблицы на разных рабочих местах.
Рис. 14.6. Если данные в поле начинают повторяться, это
признак того, что таблицу стоит поделить
4.В каждой из таблиц намечают ключевое поле. В качестве такового выбирают поле, данные в котором повторяться не могут. Например, для таблицы данных о студентах таким полем может служить индивидуальный шифр студента. Для таблицы со сведениями о постоянных подписчиках на услуги, предоставляемые фирмой, ключевым является номер контракта. Для складской таблицы ключевым может быть артикул товара.
Если в списке полей таблицы нет такого поля, которое можно было бы использовать как ключевое, его можно создать искусственно. Например, можно ввести дополнительное поле типа Счетчик — оно не может содержать повторяющиеся данные по определению.
Есть еще прием объединения двух не уникальных полей в одно уникальное.
Так, например, в таблице расписания занятий время занятия не уникальное поле, поскольку в одно и то же время занятия идут у разных групп. Номер аудитории тоже не уникальное поле, поскольку в одной аудитории могут заниматься разные группы. Но если объединить время занятия с номером аудитории, то такое составное поле станет уникальным, ведь в одно и то же время в одной аудитории две группы заниматься не могут. С таким искусственным полем может быть связан номер группы студентов, занимающихся в данное время в данной аудитории, и фамилия преподавателя, который этим занятием руководит.
5. С помощью карандаша и бумаги расчерчивают связи между таблицами. На рис. 14.7 показан пример взаимосвязи между группой таблиц, входящих в базу данных компании, занимающейся трансляцией спутниковых телевизионных каналов. Ключевые поля таблиц в ней выделены полужирным шрифтом. Такой чертеж называется схемой данных.
Рис. 14.7. Схема связей между таблицами
Существует несколько типов возможных связей между таблицами. Наиболее распространенными являются связи один ко многим и один к одному. Связь между двумя таблицами организуется на основе общего поля. Оно должно присутствовать как в той, так и в другой таблице, причем в одной из таблиц оно обязательно должно быть ключевым. То есть на стороне один всегда должно выступать ключевое поле, содержащее уникальные, неповторяющиеся значения. Значения того же поля на стороне многие могут повторяться.
Рассмотрим таблицу Клиенты (рис. 14.7). Здесь поле N Контракта является ключевым. Это понятно, поскольку с каждым клиентом заключается свой уникальный контракт, номер которого идентифицирует клиента однозначно. Если мы рассмотрим таблицу Состав пакетов, то увидим, что в ней уникально название пакета программ, поскольку у каждого пакета свой уникальный состав. Но если мы рассмотрим таблицу Подписка, то увидим, что номер контракта клиента уникален, а поле названия пакета подписки — нет, поскольку разные клиенты могли подписаться на одинаковые пакеты.
Интересно отметить, что в таблице Оплата номер контракта уже не является уникальным. Один клиент мог оплачивать услуги много раз, и каждый раз его номер контракта фиксировался.
На схеме данных общие поля соединены линиями связи. С одной стороны эта линия всегда маркируется знаком «1», с другой стороны — либо знаком «1» (связь один к одному), либо значком «бесконечность» (связь один ко многим). Понятно, что если связываются ключевые поля, то это всегда связь один к одному, а если ключевое поле связано с неключевым, то это связь один ко многим.
Про подобные таблицы говорят, что они связаны реляционными отношениями. Соответственно, системы управления, способные работать со связанными таблицами, называют системами управления реляционными базами данных, а схему данных в технической литературе могут называть схемой реляционных отношений.
6. Разработкой схемы данных заканчивается «бумажный» этап работы над техническим предложением. Эту схему заказчик согласовывает с исполнителем, и лишь после этого исполнитель может приступать к непосредственному созданию базы данных.
Следует иметь в виду, что по ходу разработки проекта заказчику непременно будут приходить в голову новые идеи. На всех этапах проектирования он будет постоянно стремиться охватить единой системой все новые и новые подразделения и службы предприятия. Возможность гибкого исполнения его пожеланий во многом определяется квалификацией разработчика базы данных. Если схема данных составлена правильно, подключать к базе новые таблицы нетрудно. Если структура базы нерациональна, разработчик испытает серьезные трудности и может войти в противоречия с заказчиком.
Противоречия исполнителя с заказчиком всегда свидетельствуют о недостаточной квалификации исполнителя. Именно поэтому этап предварительного проектирования базы данных следует считать основным. От его успеха зависит, насколько база данных станет удобной и будут ли с ней работать пользователи. Если отмечается, что пользователи базы «саботируют» ее эксплуатацию и предпочитают работать традиционными методами, это говорит не о низкой квалификации пользователей, а о недостаточной квалификации разработчика базы.
