Основные этапы разработки баз данных. Этапы разработки базы данных

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

Этапы проектирования БД:

1. Системный анализ и словесное описание информационных объектов предметной области и связей между ними.

2. Семантическое моделирование предметной области – частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, ER-модели.

3. Выбор стандартной СУБД.

4. Логическое проектирование БД, то есть описание БД в терминах принятой модели данных. На этом этапе определяются число и структура таблиц, формируются запросы к БД, определяются типы отчетных документов, разрабатываются алгоритмы обработки информации, создаются формы для ввода и редактирования данных и т.д.

5. Физическое проектирование БД, то есть выбор эффективного размещения БД на внешних носителях для обеспечения максимального быстродействия при обработке данных.

4.2 Модель «сущность-связь» (ER-модель)

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

Предположим, что проектируется база данных для предметной области БАНК. Он имеет филиалы, управляемые менеджерами. У клиентов есть счета разных типов: текущие, срочные, до востребования и т.д., которые обрабатываются в филиалах. В предметной области могут быть выделены четыре сущности: Филиал, Менеджер, Счет, Клиент.

На ER-диаграмме сущность изображается прямоугольником, в котором указывается ее имя, например:

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

В предметной области БАНК можно выделить 3 связи:

1. Менеджер Управляет Филиалом

2. Филиал Обрабатывает Счет

3. Клиент Имеет Счет

Важной характеристикой связи является тип связи (кратность) . Рассмотрим типы вышеуказанных связей. Так как один менеджер управляет только одним филиалом, то 1-я связь имеет тип «один-к-одному» (1:1).

Так как один филиал обрабатывает несколько счетов, а каждый счет обрабатывается только одним филиалом, то 2-я связь имеет тип «один-ко-многим» (1:М).

Так как один счет может совместно использоваться несколькими клиентами и один клиент может иметь несколько счетов, то 3-я связь имеет тип «многие-ко-многим» (M:N).

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

Если не каждый экземпляр сущности А связан с каким-либо экземпляром сущности В, то степень участия сущности А является необязательной . Это изображается на ER-диаграмме черным кружком, помещенным на линии связи возле сущности А.

Если каждый экземпляр сущности А связан с каким-либо экземпляром сущности В, то степень участия сущности А является обязательной . При этом на ER-диаграмме черный кружок на линии связи помещается в прямоугольник рядом с сущностью А. Напр., связь Сотрудник Регистрирует Клиентов имеет тип (1:М). При этом не каждый сотрудник регистрирует клиентов (необязательное участие), но каждый клиент регистрируется сотрудником (обязательное участие):

Предположим, что в рассматриваемой предметной области БАНК степень участия всех четырех сущностей является обязательной. Тогда ER-модель будет иметь вид:

Каждая из четырех сущностей модели может быть описана своим набором атрибутов.

ER-модель в совокупности с наборами атрибутов сущностей может служить примером семантической (концептуальной) модели предметной области или концептуальной схемы базы данных.

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

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

II этап. Анализ объекта.

На этом этапе рассматривается, из каких объектов может состоять БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, или, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи. Сведения о типах данных также следует занести в составляемую таблицу.

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

с использованием форм;

без использования форм.

Форма - это созданный пользователем графический интерфейс для ввода данных в базу.

V этап. Синтез компьютерной модели объекта.

В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

Создавая исходную таблицу, необходимо указать имя и тип каждого поля. Имена полей не должны повторяться внутри одной таблицы. В процессе работы с БД можно дополнять таблицу новыми полями. Созданную таблицу необходимо сохранить, дав ей имя, уникальное в пределах создаваемой базы.

1. Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация хранится только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.
2. Каждая таблица должна содержать информацию только на одну тему. Сведения на каждую тему обрабатываются намного легче, если они содержатся в независимых друг от друга таблицах. Например, адреса и заказы клиентов лучше хранить в разных таблицах, с тем, чтобы при удалении заказа информация о клиенте осталась в базе данных.
3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").
4. База данных должна иметь первичный ключ. Это необходимо для того, чтобы СУБД могла связать данные из разных таблиц, например, данные о клиенте и его заказы.

Стадия 3. Создание экранных форм.

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

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE - в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

поиск необходимых сведений;

сортировка данных;

отбор данных;

вывод на печать;

изменение и дополнение данных.

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

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

Такое представление уровней данных не единственное. Существуют и другие варианты многоуровневого представления данных. Так, в соответствии с предложениями исследовательской группы по системам управления данными Американского национального института стандартов ANSI/X3/SPARC, а также CODASYL (Conference on Data Systems Languages), как правило, выделяется три уровня представления данных:

· внешний уровень (с точки зрения конечного пользователя и прикладного программиста),
· концептуальный уровень (с точки зрения СУБД),
· внутренний уровень (с точки зрения системного программиста).

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

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

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

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

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

Все внешние представления интегрируются на инфологическом уровне, где формируется инфологическая (каноническая) модель данных, которая не является простой суммой внешних представлений данных.

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

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

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

Внутренний уровень связан с физическим размещением данных в памяти ЭВМ. На этом уровне формируется физическая модель БД, которая включает структуры сохранения данных в памяти ЭВМ, в т.ч. описание форматов записей, порядок их логического или физического приведения в порядок, размещение по типам устройств, а также характеристики и пути доступа к данным. От параметров физической модели зависят такие характеристики функционирования БД: объем памяти и время реакции системы. Физические параметры БД можно изменять в процессе ее эксплуатации с целью повышения эффективности функционирование системы. Изменение физических параметров не предопределяет необходимости изменения инфологической и даталогической моделей. Схема взаимосвязи уровней представления данных в БД изображена на рис.1.1. В соответствии с этими уровнями проектируется БД. Проектирование БД-- этосложный и трудоемкий процесс, который требует привлечения многих высококвалифицированных специалистов. От того, насколько квалифицированно спроектирована БД, зависят производительность информационной системы и полнота обеспечения функциональных потребностей пользователей и прикладных программ. Неудачно спроектированная БД может усложнить процесс разработки

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

Рис. 1.1.

Внешний уровень -- подготовительный этап инфологического проектирования.

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

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

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

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

1. Определение функциональных задач предметной области, которые подлежат автоматизированному решению. Поскольку основной целью создания БД есть обеспечение информацией функций обработки данных, то, прежде всего, необходимо изучить все функции предметной области (объекта управления), для которой разрабатывается база данных, и проанализировать их особенности. Функции и функциональные особенности объекта управление необходимо изучать в неразрывной связи с изучением функциональных требований к данным со стороны будущих пользователей информационной системы. Изучение и анализ предусматривают выявление информационных потребностей и определения информационных потоков. Эти работы можно выполнять обследованием предметной области и анкетированием ее сотрудников. Результатом такого изучения может быть перечень функциональных задач, которые должны решаться автоматизированным способом с использованием БД.
2. Изучение и анализ оперативных первичных документов. Изучив функции и определив перечень функциональных задач, которые подлежат автоматизированному решению, переходят к изучению оперативных документов, которые используются на входе каждой задачи или их комплекса. Изучив и проанализировав все оперативные документы (как внешние, так и внутренние), которые используются на входе каждой задачи, определяют, какие реквизиты этих документов нужно сохранять в БД.
3. Изучение нормативно-справочных документов. На третьем шаге изучают и анализируют всю нормативно-справочную документацию. К такой документации принадлежат различные классификаторы, сметы, договоры, нормативы, законодательные акты по налоговой политике, плановая документация и т.п. Распределение и отдельный анализ оперативной и нормативно-справочной информации обусловлены технологически. В базы данных различаются технологии создания и ведения файлов условно-постоянной информации, размещенной в нормативно-справочной документации, и файлов оперативной информации.
4. Изучение процессов преобразования входных сообщений в выходные.

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

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

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

Рис.1.2.

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

Результатом проектирования на внешнем уровне будет перечень атрибутов (реквизитов) оперативной и условно-постоянной информации, которые необходимо хранить в БД, с указанием источников их получения и формы представления.

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

При разработке БД можно выделить следующие этапы работы.

I этап. Постановка задачи.

II этап. Анализ объекта.

III этап. Синтез модели.

IV этап. Выбор способов представления информации и программного инструментария.

В большинстве СУБД данные можно хранить в двух видах:

с использованием форм;
без использования форм.

Форма – это созданный пользователем графический интерфейс для ввода данных в базу.

V этап. Синтез компьютерной модели объекта.

В процессе создания компьютерной модели можно выделить некоторые стадии, типичные для любой СУБД.

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

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

3. Каждая таблица должна содержать необходимые поля. Каждое поле в таблице должно содержать отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить, что каждое поле должно быть связано с темой таблицы. Не рекомендуется включать в таблицу данные, которые являются результатом выражения. В таблице должна присутствовать вся необходимая информация. Информацию следует разбивать на наименьшие логические единицы (Например, поля "Имя" и "Фамилия", а не общее поле "Имя").

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

Стадия 3. Создание экранных форм.

Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

поиск необходимых сведений;
сортировка данных;
отбор данных;
вывод на печать;
изменение и дополнение данных.

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

Содержание проектирования баз данных и этапность

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

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

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

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

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

Это обстоятельство определяет возникновение следующего этапа – появления обеспеченной средствами конкретной СУБД концептуальной модели. Данный шаг соответствует этапу логического проектирования (создания логической модели).

Наконец, финальным этапом проектирования БД становится физическое проектирование – этап увязки логической структуры и физической среды хранения.

Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

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

Ключевые из них ниже будут рассмотрены подробнее.

Инфологическое проектирование

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

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

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

Поскольку использование метода «сущность-связь» является комбинированным способом проектирования на данном этапе, он чаще других становится приоритетным.

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

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

Следует разделять понятия «экземпляр сущности» (объект, характеризующийся конкретными значениями свойств) и понятие «тип сущности» – объект, для которого характерно общее имя и список свойств.

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

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

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

Выбор системы управления и программных средств БД

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

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

Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.

Логическое проектирование БД

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

Предпочтительнее, когда естественная структура данных совпадает с представляющей её моделью. Так, например, если в данные представлены в виде иерархической структуры, то и модель лучше выбирать иерархическую. Однако на практике такой выбор чаще определяется системой управления БД, а не моделью данных. Поэтому концептуальная модель фактически транслируется в такую модель данных, которая совместима с выбранной системой управления БД.

Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.

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

Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:

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

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

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

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

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

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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