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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассмотрим таблицу Клиенты. Здесь поле Код клиента является ключе­вым. Это понятно, поскольку у каждого клиента должен быть свой уникальный код, идентифицирующий его однозначно. Если мы рассмотрим таблицу Заказы, то увидим, что в ней код клиента не может быть уникальным, поскольку каж­дый клиент мог сделать сколь угодно много заказов. На схеме данных эти поля соединены линией связи. С одной стороны эта линия маркирована знаком «1», с другой стороны — значком «бесконечность». Это графический метод изображе­ния связи «один ко многим».

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

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

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

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

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

III. Характеристика СУБД Microsoft Access 2000

СУБД Microsoft Access 2000 предоставляет несколько средств создания каждого из основных объектов базы. Эти средства можно классифицировать как:

• ручные (разработка объектов в режиме Конструктора);

• автоматизированные (разработка с помощью программ-мастеров);

• автоматические — средства ускоренной разработки простейших объектов.

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

Методической особенностью изучения программы Microsoft Access явля­ется тот факт, что в учебных целях для создания разных объектов целесообразно пользоваться разными средствами:

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

2. При разработке учебных форм, отчетов и страниц[13] доступа наоборот лучше пользо­ваться автоматизированными средствами, предоставляемыми мастерами. Это связано с тем, что для данных объектов большую роль играет внешний вид. Дизайн этих объектов весьма трудоемок, поэтому его лучше поручить программе, а учащемуся сосредоточиться на содержательной части работы.

Работа с таблицами

Создание таблиц. Работа с любыми объектами начинается с окна База данных (рис.6.12). На левой панели данного окна сосредоточены элементы управления для вызова всех семи типов объектов программы. Создание таблиц начинается с выбора элемента управления Таблицы.

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

Рис.6.12. Окно База данных является исходным элементом

управления программы Microsoft Access 2000

Окно Конструктора таблиц представлено на рис.6.13а. То, что мы видим в этом режиме, фактически является графическим бланком для создания и редактирования структуры таблиц.

Рис. 6.13. а Окно Конструктора таблиц

Рис. 6.13б Окно мастера таблиц

В первом столбце вводят имена полей. Если свойство Подпись для поля не задано, то Имя поля станет одновременно и именем столбца будущей таблицы. Тип для каждого поля выбирают из раскрывающегося списка, открывае­мого кнопкой выбора типа данных (рис. 6.14). Эта кнопка — скрытый элемент управления. Она отображается только после щелчка на поле бланка. Это надо иметь в виду — в Microsoft Access очень много таких скрытых элементов управления, кото­рые не отображаются, пока ввод данных не начат.

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

Рис. 6.14. Выбор типа поля в таблице

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

Если первичный ключ необходим для связи с другими таблицами, но ни одно из полей не является уникальным, то первичный ключ можно создать на базе двух (или более полей). Эта операция выполняется точно так же, через контекстное меню, надо только уметь выделить сразу несколько полей. Группо­вое выделение выполняют при нажатой клавише SHIFT щелчками на квадратных маркерах слева от имен полей. Закончив создание структуры таблицы, бланк закрывают (при этом система выдает запрос на сохранение таблицы), после чего дают таблице имя, и с этого момента она доступна в числе прочих таблиц в основном окне База данных. Оттуда ее и можно открыть в случае необходимости.

Дата добавления: 2014-12-29