Взаимодействие заказчика базы данных с разработчиком

 

Общие замечания

 

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

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

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

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

 

Разработка технического задания

 

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

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

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

При подготовке технического задания составляют:

• список исходных данных, с которыми работает заказчик;

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

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

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

 

Разработка схемы данных

 

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

1. Работа начинается с составления генерального списка полей — он может насчи­тывать сотни позиций.

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

3. Далее распределяют поля генерального списка по базовым таблицам. На пер­вом этапе распределение производят по функциональному признаку. Прин­цип разделения очень прост: обеспечить, чтобы ввод данных в одну таблицу производился в рамках одного подразделения, а еще лучше — на одном рабо­чем месте.

Наметив столько таблиц, сколько подразделений (рабочих мест) охватывает база данных, приступают к дальнейшему делению таблиц. Критерием необхо­димости деления является факт множественного повтора данных в соседних записях. На рис. 14.6 показана таблица, у которой в поле Адрес наблюдается повтор данных. Это явное свидетельство того, что таблицу надо поделить на две взаимосвязанных таблицы и, возможно, заполнять эти таблицы на разных рабочих местах.

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

 

Рис. 14.6. Если данные в поле начинают повторяться, это признак того, что таблицу стоит поделить

 

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

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

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

 

Рис. 14.7. Схема связей между таблицами

 

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

Рассмотрим таблицу Клиенты (рис. 14.7). Здесь поле N Контракта является клю­чевым. Это понятно, поскольку с каждым клиентом заключается свой уникаль­ный контракт, номер которого идентифицирует клиента однозначно. Если мы рассмотрим таблицу Состав пакетов, то увидим, что в ней уникально название пакета программ, поскольку у каждого пакета свой уникальный состав. Но если мы рассмотрим таблицу Подписка, то увидим, что номер контракта клиента уникален, а поле названия пакета подписки — нет, поскольку разные клиенты могли подписаться на одинаковые пакеты. Интересно отметить, что в таблице Оплата номер контракта уже не является уникальным. Один клиент мог опла­чивать услуги много раз, и каждый раз его номер контракта фиксировался.

На схеме данных общие поля соединены линиями связи. С одной стороны эта линия всегда маркируется знаком «1», с другой стороны — либо знаком «1» (связь один к одному), либо значком «бесконечность» (связь один ко многим). Понятно, что если связываются ключевые поля, то это всегда связь один к одному, а если ключевое поле связано с неключевым, то это связь один ко многим.

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

6. Разработкой схемы данных заканчивается «бумажный» этап работы над техни­ческим предложением. Эту схему заказчик согласовывает с исполнителем, и лишь после этого исполнитель может приступать к непосредственному созда­нию базы данных.

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

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

 

⇐ Предыдущая41424344454647484950Следующая ⇒

Поделиться:

Популярное:

1. I. Какое из данных утверждений выражает основную идею текста?
2. IDEF1X - методология моделирования данных, основанная на семантике, т.е. на трактовке данных в контексте их взаимосвязи с другими данными.
3. II. Особенности технологии баз и банков данных.
4. II. СПОСОБЫ И ПРИЗНАКИ ИЗМЕНЕНИЯ МАРКИРОВОЧНЫХ ДАННЫХ
5. OLAP-технология и многомерные модели данных
6. V. Составьте и запишите предложения из данных слов.
7. Автоматическое заполнение данных
8. Акт приёма-передачи базы данных
9. Анализ данных с помощью команд Подбор параметра и Поиск решения
10. Анализ информационной базы обслуживания
11. Анализ материально-технической базы производства
12. Анализ статистических данных