2014-02-02
884
Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже, если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы). Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений.
Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, студентам, преподавателям и т. п.). Первые обычно называют прикладными (функциональными) БД, а вторые – предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями).
Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений, поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и адаптивность позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без вынужденного переписывания старых приложений.
Основывая же проектирование БД на текущих и предвидимых приложениях, можно существенно ускорить создание высокоэффективной информационной системы, т.е. системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увеличивается число прикладных БД, резко возрастает уровень дублирования данных и повышается стоимость их ведения.
Таким образом, каждый из рассмотренных подходов к проектированию воздействует на результаты проектирования в разных направлениях. Желание достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной – для ее совершенствования с целью повышения эффективности обработки данных.
Основная цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, «чистый» проект БД («Каждый факт в одном месте») можно создать, используя методологию нормализации отношений. Использование строгой методологии нормализации часто заменяется применением практических методик и правил. В [5] предлагаются 4 фундаментальных правила для проектирования БД с рациональной структурой:
I. В каждой таблице должен быть уникальный идентификатор (первичный ключ). Если это правило не выполняется, то таблицу можно нормализовать, добавив столбец, уникально идентифицирующий каждую строку.
II. В таблице должны храниться сведения лишь об одном типе объектов. Например, если в таблице КНИГИ содержатся сведения о самих книгах (индекс_книги, название) и издательствах (название, адрес), то это данные о двух типах объектов. Такое хранение создает проблемы: если адрес издательства изменился, то коррективы придется вносить во все записи о книгах, изданных данным издательством. Для нормализации следует разбить таблицу КНИГИ на две: КНИГИ и ИЗДАТЕЛЬСТВА.
III. В таблице не должно быть списков значений для некоторой единицы информации. Допустим, требуется учитывать названия и авторов книг в таблице КНИГИ. У книги может быть несколько авторов. Можно, конечно, хранить список всех авторов в одном столбце, но это затруднит обработку и поиск по отдельному автору. Другое решение – изменить структуру таблицы и добавить еще один или два столбца Автор1, Автор2. А если авторов три или больше? Если необходимо хранить список значений, следует предусмотреть размещение дублирующих данных в другой таблице, связанной с главной. Для нашего примера получаем таблицы: КНИГИ(индекс_книги, название), АВТОРЫ(код_автора, ФИО), КНИГИ_АВТОРЫ(индекс_книги, код_автора). Такая структура позволяет описать книгу с любым числом авторов без изменеия определения таблицы и не допускает наличия пустых мест при сохранении книги с одним автором.
IV. В таблицах следует избегать столбцов, допускающих пустые значения.
Фундаментальные правила можно дополнить практическими рекомендации, которые рекомендует Б. Послед [9]:
1. Предусмотреть возможность добавления таблиц, полей таким образом, чтобы не пришлось все переделывать.
2. Нужно рационально распределить информацию по таблицам. Обычно вся информация хранится в таблицах двух типов:
· базовые, содержащие записи об основных объектах и событиях ПО (накладные, счета и т.д.)
· таблицы-справочники, элементы которых состоят из уникального номера и описания, например справочник Товары может содержать следующие поля: номер товара; наименование; единица измерения; категория и т.д.
3. Связать все базовые таблицы со справочниками.
4. По возможности использовать индексы. Это ускоряет сортировку и поиск информации.
