Лекция 9.3. Проектирование БД
Режимы работы с БД
Обычно с БД работают две категории исполнителей. Первая – проектировщики. Их задача состоит в разработке структуры таблиц БД и согласование ее заказчиком. Кроме таблиц проектировщики разрабатывают и др. объекты БД, предназначенные, с одной стороны, для автоматизации работы с базой, а с другой – для ограничения функциональных возможностей работы с базой (если это необходимо из соображений безопасности). Проектировщики не наполняют базу конкретными данными - заказчик может считать их конфиденциальными и не предоставлять посторонним лицам. Исключение составляет экспериментальное наполнение модельными данными на этапе отладки объектов базы.
Вторая категория - пользователи. Получают исходную базу от проектировщиков и занимаются ее наполнением и обслуживанием. В общем случае пользователи не имеют средств доступа к управлению структурой базы - только к данным, да и то не ко всем, а к тем, работа с которыми предусмотрена на конкретном рабочем месте.
Соответственно СУБД имеет два режима работы: проектировочный и пользовательский. Первый предназначен для создания или изменения структуры базы и ее объектов. Во втором режиме происходит использование ранее подготовленных объектов для пополнения базы или получения данных из нее.
Объекты БД
Кроме таблиц БД может содержать и другие типы объектов. Каждая СУБД может реализовывать свои типы объектов. Поэтому привести полную классификацию возможных объектов БД затруднительно. Рассмотрим основные типы объектов на примере СУБД Microsoft Access 2000. Эта СУБД позволяет создавать и использовать объекты семи различных типов.
Таблицы – это основные объекты любой БД. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).
Запросы служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. С помощью запросов выполняется отбор данных, их сортировка и фильтрация. Можно выполнять преобразование данных по заданному алгоритму, создавать новые таблицы, выполнять автоматическое наполнение таблиц данными, импортированными из других источников, выполнять простейшие вычисления в таблицах и многое другое. Все те же операции можно делать и с таблицами. Но запросы используют из соображения удобства (в первую очередь быстродействия) и соображения безопасности. Из соображений безопасности, чем меньше доступа к базовым таблицам имеют конечные пользователи, тем лучше. Во-первых, снижается риск повреждения данных в таблицах неумелыми действиями. Во-вторых, можно эффективно разграничивать доступ к данным, предоставив разным пользователям разные запросы в строгом соответствии с кругом персональных обязанностей. Например, в банках одни сотрудники имеют доступ к таблицам данных о клиенте, другие - к их расчетным счетам, третьи - к таблицам активов банка. Специалисты, имеющие доступ ко всем информационным ресурсам банка, лишены средств, для внесения изменений. Все сделано для того, чтобы один человек не мог совершить фиктивную операцию, независимо от того, какую должность он занимает.
Особенность запросов состоит в том, что они черпают данные из базовых таблиц и создают на их основе временную результирующую таблицу (ее еще называют моментальным снимком).
При работе с основными таблицами базы, имеют дело с жестким диском, т.е. очень медленным устройством. При получении результирующей таблицы на основании запроса имеют дело с электронной таблицей, не имеющей аналога на жестком диске – это только образ отобранных полей и записей. Разумеется, работа с «образом» происходит гораздо быстрее и эффективнее. Это еще одно основание широкого использования запроса.
В СУБД от базовых таблиц не требуется никакой упорядоченности. Все записи в основные таблицы вносят по мере их поступления, т.е. в неупорядоченном виде. Если надо видеть данные, отсортированные или отфильтрованные по какому-либо принципу, для этого также используется соответствующий запрос.
Формы. Если запросы – это специальные средства для отбора и анализа данных, то формы – это средства для ввода данных. Смысл их тот же – предоставить пользователю средства для заполнения только тех полей, которые ему заполнять положено. Одновременно с этим в форме можно разместить специальные элементы управления для автоматизации ввода (счетчики, раскрывающие списки, переключатели, флажки и прочее). Преимущества раскрываются особенно наглядно, когда происходит ввод данных с заполненных бланков. В этом случае форму делают так, чтобы она повторяла оформление бланка – это заметно упрощает работу наборщика, снижает его утомляемость и предотвращает появления печатных ошибок. Формы являются основными объектами для работы с данными, перемещения по записям и подтверждения выполнения различных операций с БД.
Отчеты. По своим свойствам и структуре отчеты во многом похожи на формы, но предназначены только для вывода данных, причем не на экран, а на печатающее устройство (принтер). В связи с этим, отчеты отличаются тем, что в них приняты специальные меры для группирования выводимых данных и для ввода специальных элементов оформления, характерных для печатных документов (верхний и нижний колонтитулы, номера страниц, служебная информация о времени создания отчета и т.п.).
Макросы. Эти объекты предназначены для автоматизации повторяющихся операций при работе с СУБД. В СУБД MS Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой.
Модули предназначены для создания новых функций путем программирования. Эти объекты создаются средствами внешнего языка программирования, в данном случае, языка Visual Basic for applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные, функциональные возможности, удовлетворяя специфические требования заказчика, повысить быстродействие системы управления, а также уровень ее защищенности.
Проектирование БД
Методически правильно начинать работу с карандашом и листом бумаги, не используя компьютер. Неоптимальные решения и прямые ошибки, заложенные на этапе проектирования, в последствии очень трудно устраняются, поэтому этот этап является основополагающим.
Разработка технического задания
Техническое задание на проектирование БД должен предоставить заказчик. Но для этого он должен владеть соответствующей терминологией и знать, хотя бы в общих чертах, технические возможности основных СУБД. Поэтому обычно используют следующие подходы:
· Демонстрируют заказчику работу аналогичной БД, после чего согласовывают спецификацию отличий;
· Если аналога нет, выясняют круг задач и потребностей заказчика, после чего помогают ему подготовить техническое задание.
При подготовке технического задания составляют:
· Список исходных данных, с которыми работает заказчик;
· Список выходных данных, которые необходимы заказчику для управления структурой своего предприятия;
· Список выходных данных, которые не являются необходимыми для заказчика, но которые он должен предоставить в другие организации (в вышестоящие структуры, в органы статистического учета, прочие административные и контролирующие организации).
Разработка структуры БД
Выяснив основную часть данных, которые заказчик потребляет или поставляет, можно приступать к созданию структуры базы, т.е. структуры ее основных таблиц.
1. Работа начинается с составления генерального списка полей – он может насчитывать десятки и даже сотни позиций.
2. В соответствии с типом данных, размещаемых в каждом поле, определяют наиболее подходящий тип для каждого поля.
3. Далее распределяют поля генерального списка по базовым таблицам. Цель - обеспечить, чтобы ввод данных в одну таблицу производился, по возможности, в рамках одного подразделения, а еще лучше – на одном рабочем месте.
4. Наметив столько таблиц, сколько подразделений охватывает база данных, приступают к дальнейшему делению таблиц. Критерием деления является факт множественного повтора данных в соседних записях. Например, табл. 9.3.1.
Таблица 9.3.1.
Сведения о процессор
| Марка | модель | цена | поставщик | Адрес |
| Celeron | 300А | ООО «Самшит» | 123456, Москва, ул. Индустриальная, д.10 | |
| Celeron | ООО «Самшит» | 123456, Москва, ул. Индустриальная, д.10 | ||
| Intel | ТОО «Планета» | 111222, Москва, ул. Промышленная, д.22 | ||
| Celeron | ООО «Самшит» | 123456, Москва, ул. Индустриальная, д.10 | ||
| Intel | ЗАО «Кристина» | 121212, Москва, пр. Технический, 44 |
В данной таблице в полях «Поставщик» и «Адрес» наблюдается повтор данных. Это говорит о том, таблицу надо поделить на две взаимосвязанные таблицы (табл. 7.3.2 и табл. 7.3.3).
Таблица 9.3.2.
«Процессор»
| Марка | модель | цена |
| Celeron | 300А | |
| Celeron | ||
| Intel | ||
| Celeron | ||
| Intel |
Таблица 9.3.3.
«Поставщики»
| Наименование | Индекс | Город | Адрес | Телефон |
| ООО «Самшит» | Москва | ул. Индустриальная, д.10 | 129-62-51 | |
| ТОО «Планета» | Москва | ул. Промышленная, д.22 | 456-43-21 | |
| ЗАО «Кристина» | Москва | пр. Технический, 44 | 175-84-22 |
5. В каждой из таблиц намечают ключевое поле.В качестве такового выбирают поле, данные в котором повторяться не могут. Например, для таблицы данных о студентах таким полем может служить индивидуальный шифр студента (№ зачетной книжки). Для таблицы 9.3.2 «Процессор» такого поля нет, но его можно создать искусственно комбинированием полей «Марка » и «Модель». Эта комбинация неповторима, т.к. в таблице незачем описывать одну и ту же модель.
Если же в таблице таких полей нет, которые можно было бы использовать как ключевые, всегда можно ввести дополнительное поле типа Счетчик – оно не может содержать повторяющихся данных по определению. Например, в таблицу 9.3.3 «Поставщики» можно ввести поле «Код поставщика».
| Код поставщика | Наименование | Индекс | Город | Адрес | Телефон |
| ООО «Самшит» | Москва | ул. Индустриальная, д.10 | 129-62-51 | ||
| ТОО «Планета» | Москва | ул. Промышленная, д.22 | 456-43-21 | ||
| ЗАО «Кристина» | Москва | пр. Технический, 44 | 175-84-22 |
6. С помощью карандаша и бумаги расчерчивают связи между таблицами. Существует несколько типов возможных связей между таблицами. Наиболее распространенными являются связи «один ко многим» и «один к одному». Связь между таблицами организуется на основе общего поля, причем в одной из таблиц оно обязательно должно быть ключевым, т.е. на стороне «один» должно выступать ключевое поле, содержащее уникальные, неповторяющиеся значения. Значения на стороне «многие» могут повторяться.
Для того, чтобы можно было получать сведения о поставщиках процессоров, надо связать таблицы 9.3.2 и 9.3.3. Чтобы можно было осуществить связь, в таблице «Поставщики» поле «Код поставщика» надо сделать ключевым. В таблицу 9.3.2. надо добавить поле «Код поставщика» и связать таблицы по этому полю (рис. 9.3.1).
|
|
1
 |
Рис. 9.3.1. Схема связей между таблицами
Про подобные таблицы говорят, что они связаны реляционными отношениями. Соответственно, системы управления, способные работать со связанными таблицами, называются системами управления реляционными БД, а схему данных могут называть схемой реляционных отношений.
7. Разработкой схемы данных заканчивается «бумажный» этап работы над техническим предложением. Схему можно согласовать с заказчиком, после чего приступать к непосредственному созданию БД.