Сопоставление методик нормализации и e-r проектирования. Физическое проектирование.

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

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

При использовании E-R методики проектирование идет как бы в обратном порядке. Выделяя из предметной области сущности и ключи сущностей, мы как бы строим основу для пятой нормальной формы – сразу и без промежуточных преобразований данных. Построение предварительных отношений по E-R диаграммам – это построение VНФ, хотя и без второстепенных атрибутов, которые будут добавлены позже. «Расплатой» за эту видимую эффективность является большая зависимость результата проектирования от опыта и знаний проектировщика, особенно на этапе выделения сущностей и их ключей. Понятие функциональной зависимости, без которого удается обходиться вплоть до этапа построения предварительных отношений, все же возникает, при распределении неключевых атрибутов по отношениям.

Построение концептуальной модели данных не завершает этап проектирования БД. Из рис.1 следует, что концептуальная модель – важное, но не единственное представление данных. Если разработка внешних представлений является частью разработки приложений, то разработка внутренней модели или физическое проектирование – это прерогатива проектировщика БД.

Физическое проектирование.

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

Одно из самых важных решений, принимаемых здесь – какая именно СУБД будет использована при создании банка данных. В идеале для решения задачи должна использоваться та СУБД, которая позволяет наиболее эффективно решить поставленную задачу. Однако, на практике используется то «что есть под рукой», та СУБД, которая закуплена и установлена у разработчика, с которой имеется опыт работы и т.д.

Следующая, и не менее важная проблема – какие будут использоваться технологии доступа к данным. На современном этапе развития СУБД принято подразделять эти технологии на «файл – сервер» и «клиент – сервер». Технология «файл – сервер» предполагает, каждое приложение осуществляет доступ по сети к тому компьютеру, где хранятся файлы, и который, собственно, и называется файловым сервером. При этом каждое из приложений взаимодействует лишь с операционной системой файл – сервера. В рамках появившейся позже технологии «клиент – сервер» предполагается наличие на сервере специфичного приложения, с которым взаимодействуют приложения рабочих станций («клиенты»). При этом резко уменьшается объем передаваемых по сети данных, за счет того, что клиентские приложения передают на сервер не сами данные, а запросы на их изменение.

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

Несколько проще обстоит дело с выбором форматов таблиц и индексных файлов. С одной стороны, каждая СУБД предоставляет пользователю ограниченное число форматов хранения, обычно 1-2, не более. С другой – доступ к данным с помощью драйверов ODBC делает все СУБД, работающие в среде Windows до какой- то степени «форматно- независимыми».

Что же касается выбора индексных выражений, то совершенно ясно, что от их оптимального выбора зависит скорость работы приложений. Здесь общепринятой практикой является назначение индексов по всем первичным и внешним ключам всех отношений. Кроме того, индексы часто назначаются полям, по которым часто может проводится сортировка данных. Например, в таблице с анкетными данными студентов (см. разобранные выше примеры) поле «Фамилия» не является ключевым, однако по нему возможна и сортировка данных (упорядочение по алфавиту), и поисковые операции. Приложения будут работать заметно быстрее, если по этому полю будет создан индекс. Разумеется, количество индексов не стоит увеличивать сверх меры, поскольку слишком большое их число может дать и обратный эффект – скорость выполнения снизится за счет перегрузки каналов обмена информацией.