При создании базы данных можно выделить следующие этапы:

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

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

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

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

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

17. ТАБЛИЦЫ

Таблица - объект базы данных, который используется для хранения данных.

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

Запись - строка таблицы базы данных, в которой собрана вся информация о конкретном предмете. Например, в таблице «Книги» базы данных «Библиотека» - это информация о конкретной книге.

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

СТРУКТУРА ТАБЛИЦЫ

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

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

Рис. 3.5.

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

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

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

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

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

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

Транзакция - процесс изменения файла, записи или базы данных , вызванный передачей одного входного сообщения.

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

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

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

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

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

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

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

Основными причинами низкой эффективности проектируемых БД могут быть:

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

В этих условиях вопросы автоматизации разработки становятся первостепенными.

Основные этапы разработки БД

Этап 1. Уточнение задач

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

Этап 2. Последовательность выполнения задач

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

Этап 3. Анализ данных

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

Этап 4. Определение структуры данных

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

Этап 5. Разработка макета приложения и пользовательского интерфейса

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

Этап 6. Создание приложения

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

Этап 7. Тестирование и усовершенствование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.1.

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

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

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

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

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

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

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

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

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

Рис.1.2.

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

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

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

Этапы проектирования базы данных

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

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

2. БД должна обеспечивать получение требуемых данных за приемлемое время, т.е. отвечать требованиям производительности;

3. БД должна легко расширяться при реорганизации предметной области;

4. БД должна легко изменяться при изменении программной и аппаратной среды;

5. Корректные данные, загруженные в БД, должны оставаться корректными (данные должны проверяться на корректность при их вводе).

Рассмотрим основные этапы проектирования (рис. 3.5):

Первый этап . Планирование разработки базы данных. На этом этапе выделятся наиболее эффективный способ реализации этапов жизненного цикла системы.

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

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

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

Рис. 3.5. Схема проектирования БД

b) Уточнение последовательности выполнения задач. Чтобы приложение работало логично и удобно, лучше всего объединить основные задачи в группы и затем упорядочить задачи каждой группы так, чтобы они располагались в порядке их выполнения. Группировка и графическое представление последовательности их выполнения поможет определить естественный порядок выполнения задач.

c) Анализ данных. После определения списка задач необходимо для каждой задачи составить подробный перечень данных, требуемых для ее решения. После этапа анализа данных можно приступать к разработке концептуальной модели, т.е. к выделению объектов, атрибутов и связей.

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

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

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

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

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

Восьмой этап . Тестирование и оптимизация. Обязательным этапом является тестирование и оптимизация разработанного приложения.

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

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

Наименование параметра	Значение
Тема статьи:	Этапы проектирования баз данных
Рубрика (тематическая категория)	Связь

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

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

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

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

Перед созданием базы данных крайне важно располагать описанием выбранной предметной области, ĸᴏᴛᴏᴩᴏᴇ должно охватывать реальные объекты и процессы, определить всœе необходимые источники информации для удовлетворения предполагаемых запросов пользователœей и определить потребности в обработке данных.

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

Этапы проектирования и создания базы данных определяются следующей последовательностью:

‣‣‣ построение информационно-логической модели данных предметной области;

‣‣‣ определœение логической структуры реляционной базы данных;

‣‣‣ конструирование таблиц базы данных;

‣‣‣ создание схемы данных;

‣‣‣ ввод данных в таблицы (создание записей);

‣‣‣ выработка необходимых форм, запросов, макросов, модулей, отчетов;

‣‣‣ выработка пользовательского интерфейса.

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

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

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

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

Рассмотрим формальные правила, которые бывают использованы для выделœения информационных объектов.

‣‣‣ на базе описания предметной области выявить документы и их атрибуты, подлежащие хранению в базе данных;

‣‣‣ определить функциональные зависимости между атрибутами;

‣‣‣ выбрать всœе зависимые атрибуты и указать для каждого всœе его ключевые атрибуты, т. е. те, от которых он зависит;

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

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

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

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

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

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

2 Проектирование базы данных на базе модели типа объект-отношение

Имеется целый ряд методик создания информационно-логических моделœей. Одна из наиболее популярных в настоящее время методик при разработке моделœей использует ERD (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют ʼʼобъект - отношениеʼʼ либо ʼʼсущность - связьʼʼ. Модель ERD была предложена Питером Пин Шен Ченом в 1976 ᴦ. К настоящему времени разработано несколько ее разновидностей, но всœе они базируются на графических диаграммах, предложенных Ченом. Диаграммы конструируются из небольшого числа компонентов. Благодаря наглядности представления они широко используются в CASE-средствах (Computer Aided Software Engineering).

Рассмотрим используемую терминологию и обозначения.

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

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

‣‣‣ иметь уникальное имя; причем к этому имени должна всœегда применяться одна и та же интерпретация (определœение сущности). И наоборот: одна и та же интерпретация не может применяться к различным именам, в случае если только они не являются псевдонимами;

‣‣‣ обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются ею через связь;

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

Сущность должна быть независимой либо зависимой. Признаком зависимой сущности служит наличие у нее наследуемых через связь атрибутов (рис. 1.).

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

Связь (Relationship) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Одна из участвующих в связи сущностей - независимая, принято называть родительской сущностью, другая - зависимая, принято называть дочерней или сущностью-потомком. Как правило, каждый экземпляр родительской сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров дочерней сущности. Каждый экземпляр сущности-потомка ассоциирован в точности с одним экземпляром сущности-родителя. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, экземпляр сущности-потомка может существовать только при существовании сущности-родителя.

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

К примеру, связь продавца с контрактом должна быть определœена следующим образом:

‣‣‣ продавец может получить вознаграждение за один или более Контрактов;

‣‣‣ контракт должен быть инициирован ровно одним Продавцом.

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

Атрибут - любая характеристика сущности, значимая для рассматриваемой предметной области. Он предназначен для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик (свойств), ассоциированных с множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т. д.) (рис. 3). Экземпляр атрибута - это определœенная характеристика конкретного экземпляра сущности. Экземпляр атрибута определяется типом характеристики (к примеру, ʼʼЦветʼʼ) и ее значением (к примеру, ʼʼлиловыйʼʼ), называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Каждый экземпляр сущности должен обладать одним конкретным значением для каждого своего атрибута.

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

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

Характер идентификации отображается в диаграмме на линии связи (рис. 4).

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

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

Сегодня на базе подхода Чена создана методология IDEF1X, которая разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEFlX-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

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

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

Идентифицирующая связь между сущностью-родителœем и сущностью-потомком изображается сплошной линией. На рис. 5: №2 - зависимая сущность, Связь 1 - идентифицирующая связь. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи должна быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).

Штриховая линия изображает неидентифицирующую связь. На рис. 5: №4 - независимая сущность, Связь 2 - неидентифицирующая связь. Сущность-потомок в неидентифицируюшей связи будет независимой от идентификатора, в случае если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, ĸᴏᴛᴏᴩᴏᴇ может существовать для каждого экземпляра сущности-родителя). В IDEF1X бывают выражены следующие мощности связей:

‣‣‣ каждый экземпляр сущности-родителя может иметь ноль, один или более связанных с ним экземпляров сущности-потомка;

‣‣‣ каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

‣‣‣ каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

‣‣‣ каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Мощность связи обозначается, как показано на рис. 6 (мощность по умолчанию - N).

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

В результате получается информационно-логическая модель, которая используется рядом распространенных CASE-средств, таких, как ERwin, Design/IDEF. В свою очередь, CASE-технологии имеют высокие потенциальные возможности при разработке баз данных и информационных систем, а именно, увеличение производительности труда, улучшение качества программных продуктов, поддержка унифицированного и согласованного стиля работы.

Этапы проектирования баз данных - понятие и виды. Классификация и особенности категории "Этапы проектирования баз данных" 2017, 2018.