Проектирование баз данных

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

     Обычно  на основании физической модели создается DDL -скрипт для создания объектов базы данных либо эти объекты создаются  непосредственно из CASE-средства — подавляющее большинство современных средств такого класса поддерживает различные механизмы доступа к данным и может выступать в роли клиентского приложения, инициирующего выполнение DDL-скриптов.

     В процессе физического проектирования следует определить наименования таблиц и типы данных для всех полей. Если необходимо, на этом же этапе описываются  представления (если таковые будут  создаваться) и может быть создан код хранимых процедур. Далее обычно полагается определить, какие именно объекты и как будут создаваться: например, с помощью каких SQL-предложений  создаются индексы, с помощью  каких объектов — триггеров или серверных ограничений — реализуется ссылочная целостность, создаются ли индексы для альтернативных ключей и т.д.

     Пример  диаграммы, отображающей физическую модель для SQL Server 7.0, соответствующую приведенной  выше логической модели, представлен  на рис. 2.

Рис. 2. Пример простейшей физической модели данных.

     Как правило, современные средства проектирования данных поддерживают несколько типов  СУБД (например, ERwin фирмы Computer Associates поддерживает более 20 различных СУБД). Уровень поддержки той или иной платформы в разных средствах проектирования данных может быть различен. Например, конкретное средство может поддерживать или не поддерживать для данной СУБД такие особенности, как создание хранимых процедур, генерация объектов физической памяти (табличных пространств, сегментов отката и др.), задание местоположения объектов базы данных в физических объектах и т.д. Поэтому, выбирая средство проектирования данных для решения конкретной задачи, стоит поинтересоваться, каковы его возможности с точки зрения поддержки особенностей той или иной платформы — при удачном раскладе можно сэкономить немало времени на «ручное» доведение создаваемой базы данных (или DDL-скрипта для ее генерации) до необходимого состояния. При этом, естественно, чем больше возможностей и платформ поддерживает конкретное средство проектирования данных, тем дороже оно стоит (следует отметить, что CASE-средства вообще относятся к не самым дешевым программным продуктам — цены на них составляют обычно от одной до нескольких десятков тысяч долларов).

     Отметим, что физическое проектирование может  включать и дополнительную «ручную» работу по доведению базы данных или  скрипта для ее генерации до «товарного» вида. Например, нередко в скрипт также включаются SQL-предложения для заполнения некоторых таблиц, данные которых более или менее постоянны, таких, например, как список субъектов Российской Федерации или справочник телефонных кодов различных стран, а также нестандартные триггеры и процедуры.

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

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

     Кроме того, подавляющее большинство средств проектирования данных позволяют восстанавливать физическую модель данных их системного каталога и представлять ее в виде ER-диаграммы (этот процесс называется обратным проектированием — reverse engineering), а также производить синхронизацию системного каталога и физической модели. При создании информационной системы, которая должна использовать унаследованные от предшествующих ей систем данные, такая особенность весьма полезна — в этом случае логическое проектирование можно начать с модификации уже имеющейся модели (этот процесс получил название round-trip engineering).

Глава 3. Разработка базы данных 

3.1. Смена принципов проектирования

     До  сих пор по умолчанию предполагалось, что данные в базе обладают некоторой  структурой. Например, на рис. 1.5 показаны четыре таблицы: PropertyForRent, PrivateOwner, Client и Lease. Но как была получена такая структура? Ответ на этот вопрос достаточно прост: структура базы данных определяется во время ее проектирования. Однако сам процесс проектирования базы данных может оказаться чрезвычайно сложным. Для создания системы, которая удовлетворяла бы информационным потребностям некоторой организации, необходимо использовать подход, совершенно отличающийся от методов разработки обычных файловых систем, в которых вся работа заключается в разработке приложений, удовлетворяющих нуждам отдельных подразделений. Для успешной реализации системы на основе базы данных необходимо подумать, прежде всего, о данных и лишь потом о приложениях. Такая смена подхода вполне может расцениваться как смена принципов проектирования. Чтобы система полностью удовлетворяла запросам пользователей, необходимо очень внимательно отнестись к процессу проектирования базы данных. Плохо спроектированная база данных будет порождать ошибки, способные привести к принятию неправильных решений, которые повлекут за собой самые серьезные последствия для данной организации. С другой стороны, хорошо спроектированная база данных позволит создать систему, поставляющую корректную информацию, которая может успешно использоваться для принятия правильных и эффективных решений. 
К сожалению, существующие методологии проектирования баз данных пока не получили широкого распространения. Большинство организаций или отдельных разработчиков при проектировании баз данных в очень незначительной степени полагается на какие-либо методологии. Именно это обстоятельство часто считается основной причиной неудач при разработке информационных систем. Из-за отсутствия структурированных подходов к проектированию баз данных необходимые для проведения разработки время и ресурсы обычно недооцениваются, а созданные базы данных часто неэффективны или не отвечают требованиям прикладных приложений.

     3.2. Распределение обязанностей в системах с базами данных

     В этом разделе мы рассмотрим упомянутый выше пятый компонент среды СУБД — ее пользователей. Среди них  можно выделить четыре различные  группы: администраторы данных и баз  данных, разработчики баз данных, прикладные программисты и конечные пользователи.

     3.2.1. Администраторы данных и администраторы баз данных

     База  данных и СУБД являются корпоративными ресурсами, которыми следует управлять  так же, как и любыми другими  ресурсами. Обычно управление данными  и базой данных предусматривает  управление и контроль за СУБД и помещенными в нее данными. Администратор данных, или АД (Data Administrator — DA), отвечает за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, прикладных алгоритмов и деловых процедур, а также за концептуальное и логическое проектирование базы данных. АД консультирует и дает свои рекомендации, руководству высшего звена, контролируя соответствие общего направления развития базы данных установленным корпоративным целям.

     Администратор базы данных, или АБД (Database Administrator — DBA), отвечает за физическую реализацию базы данных, включая физическое проектирование и воплощение проекта, за обеспечение безопасности и целостности данных, за сопровождение операционной системы, а также за обеспечение максимальной производительности приложений и пользователей. По сравнению с АД обязанности АБД носят более технический характер, и для него необходимо знание конкретной СУБД и системного окружения. В одних организациях между этими ролями не делается различий, а в других важность корпоративных ресурсов отражена именно в выделении отдельных групп персонала с указанным кругом обязанностей.

     3.2.2. Разработчики баз данных

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

• Любой сотрудник не может отвечать одновременно более чем за сто сдаваемых в аренду или продаваемых объектов недвижимости.
• Любой сотрудник не имеет права продавать или сдавать в аренду свою собственную недвижимость.
• Доверенное лицо не может выступать одновременно и как покупатель, и как продавец недвижимости.

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

• Концептуальное проектирование базы данных, которое совершенно не зависит от таких деталей ее воплощения, как конкретная целевая СУБД, приложения, языки программирования или любые другие физические характеристики.
• Логическое проектирование базы данных, которое проводится с учетом особенностей выбранной модели данных: реляционной, сетевой, иерархической или объектно-ориентированной.

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

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

     Многие  этапы физического проектирования базы данных в значительной степени  зависят от выбранной целевой  СУБД, а потому может существовать несколько различных способов воплощения требуемой схемы. Следовательно, разработчик  физической базы данных должен разбираться  в функциональных возможностях целевой  СУБД и понимать достоинства и  недостатки каждого возможного варианта реализации. Разработчик физической базы данных должен уметь выбрать  наиболее подходящую стратегию хранения данных с учетом всех существующих особенностей их использования. Если концептуальное и логическое проектирование базы данных отвечает на вопрос «что?», то физическое проектирование отвечает на вопрос «как?». Для решения этих задач требуются разные навыки работы, которыми чаще всего обладают разные люди. 

     3.2.3. Прикладные программисты

     Сразу после создания базы данных следует  приступить к разработке приложений, предоставляющих пользователям  необходимые им функциональные возможности. Именно эту работу и выполняют  прикладные программисты. Обычно прикладные программисты работают на основе спецификаций, созданных системными аналитиками. Как правило, каждая программа содержит некоторые операторы, требующие от СУБД выполнения определенных действий с базой данных — например, таких как извлечение, вставка, обновление или удаление данных. Как уже упоминалось в предыдущем разделе, эти программы могут создаваться на различных языках программирования третьего или четвертого поколения.

     3.2.4. Пользователи

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

• Рядовые пользователи. Эти пользователи обычно даже и не подозревают о наличии СУБД. Они обращаются к базе данных с помощью специальных приложений, позволяющих в максимальной степени упростить выполняемые ими операции. Такие пользователи инициируют выполнение операций базы данных, вводя простейшие команды или выбирая команды меню. Это значит, что таким пользователям не нужно ничего знать о базе данных или СУБД. Например, чтобы узнать цену товара, кассир в супермаркете использует сканер для считывания, нанесенного на него штрих-кода. В результате этого простейшего действия специальная программа не только считывает штрих-код, но и выбирает на основе его значения цену товара из базы данных, а также уменьшает значение в другом поле базы данных, обозначающем остаток таких товаров на складе, после чего выбивает цену и общую стоимость на кассовом аппарате.

     Опытные пользователи. С другой стороны спектра находятся опытные конечные пользователи, которые знакомы со структурой базы данных и возможностями СУБД. Для выполнения требуемых операций они могут использовать такой язык запросов высокого уровня, как SQL. А некоторые опытные пользователи могут даже создавать собственные прикладные программы.

     Заключение

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