Телевизор 

Этапы проектирования бд. Процесс проектирования базы данных. Основные задачи проектирования баз данных


Рис. 3.5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

1.1. Реляционная база данных и ее структура

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

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

Строки таблицы называются записями . Все записи таблицы имеют одинаковую структуру – они состоят изполей (элементов данных), в которых хранятся атрибуты объекта (рис. 1). Каждое поле записи содержит одну характеристику объекта и представляет собой заданный тип данных (например, текстовая строка, число, дата). Для идентификации записей используется первичный ключ.Первичным ключом называется набор полей таблицы, комбинация значений которых однозначно определяет каждую запись в таблице.

Рис. 1. Названия объектов в таблице

Для работы с данными используются системы управления базами данных (СУБД). Основные функции СУБД:

– определение данных (описание структуры баз данных);

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

– управление данными.

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

Любая СУБД позволяет выполнять следующие операции с данными:

– добавление записей в таблицы;

– удаление записей из таблицы;

– обновление значений некоторых полей в одной или нескольких записях в таблицах БД;

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

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

«язык структурированных запросов» (SQL – Structured Query Language).

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

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

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

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

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

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

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

1.2.1. Определение требований

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

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

Таблица 1

Словарь данных для приложения БД менеджера турфирмы

Элемент данных

Описание

Фамилия туриста

Имя туриста

Отчество

Отчество туриста

Серия и номер паспорта туриста

Контактный телефон туриста

Город проживания туриста

Страна проживания туриста

Почтовый индекс адреса туриста

Название туристической поездки

Цена туристической поездки

Дата начала

Время начала туристической поездки

Дата конца

Время завершения туристической поездки

Информация

Дополнительная информация о туре

Дата оплаты

Дата оплаты путевки

Сумма оплаты

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

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

Функциональное описание для приложения БД менеджера турфирмы могло бы включать, например, следующие требования:

Приложением будут пользоваться руководитель турфирмы, 2 менеджера по продажам, бухгалтер, кассир и 2 офисных сотрудника турфирмы – всего 7 пользователей. Предполагается, что одновременно с БД будут работать не более 3 сотрудников. Персоналу бухгалтерии для работы достаточно иметь доступ только к данным по оплате путевок.

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

Один из офисных сотрудников будет назначен системным администратором. Только он должен вести учетные записи пользователей.

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

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

1.2.2. Логическая модель

ER-диаграммы

Общим способом представления логической модели БД является построение ER-диаграмм (Entity-Relationship – сущность-связь). В этой модели сущность определяется как дискретный объект, для которого сохраняются элементы данных, а связь описывает отношение между двумя объектами.

В примере менеджера турфирмы имеются 5 основных объектов:

Туристы

Туры

Путевки

Сезоны

Оплаты

Отношения между этими объектами могут быть определены простыми терминами:

Каждый турист может купить одну или несколько (много) путевок.

Каждой путевке соответствует ее оплата (оплат

может быть и несколько,

если путевка, например,

продана в кредит).

Каждый тур может иметь

несколько сезонов.

Путевка

продается

один сезон одного тура.

Эти объекты и отношения

могут быть представлены ER-

диаграммой,

как показано

Рис. 2. ER-диаграмма для приложения БД

менеджера турфирмы

Объекты, атрибуты и ключи

Далее модель развивается путем определения атрибутов для каждого объекта. Атрибуты объекта – это элементы данных, относящиеся к определенному объекту, которые должны сохраняться. Анализируем составленный словарь данных, выделяем в нем объекты и их атрибуты, расширяем словарь при необходимости. Атрибуты для каждого объекта в рассматриваемом примере представлены в таблице 2.

Объекты и атрибуты БД

Таблица 2

Название

Дата начала

Дата оплаты

Дата конца

Отчество

Информация

Атрибуты

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

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

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

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

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

Для проектируемой БД расширим атрибуты объектов кодовыми полями в качестве первичных ключей и используем эти коды в отношениях БД для ссылки на объекты БД следующим образом (табл. 3).

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

Объекты и атрибуты БД с расширенными кодовыми полями

Таблица 3

Код туриста

Код путевки

Код сезона

Код оплаты

Код туриста

Название

Дата начала

Дата оплаты

Атрибуты

Код сезона

Дата конца

Отчество

Информация

Код путевки

Нормализация

Функциональные зависимости проявляются, когда значение одного атрибута может быть определено из значения другого атрибута. Атрибут, который может быть определен, называетсяфункционально зависимым от атрибута, который является детерминантом. Следовательно, по определению, все неключевые (без ключа) атрибуты будут функционально зависеть от первичного ключа в каждом отношении (так как первичный ключ уникально определяет каждую строку). Когда один атрибут отношения уникально не определяет другой атрибут, но ограничивает его набором предопределенных значений, это называетсямногозначной зависимостью.Частичная зависимость имеет место, когда атрибут отношения функционально зависит от одного атрибута составного ключа. Транзитивные зависимости наблюдаются, когда неключевой атрибут функционально зависит от одного или нескольких других неключевых атрибутов в отношении.

Процесс нормализации состоит в пошаговом построении БД в нормальной форме (НФ).

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

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

Третья нормальная форма (3НФ) БД требует удаления всех транзитивных зависимостей.

Четвертая нормальная форма (4НФ) создается при удалении всех многозначных зависимостей.

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

Обратите внимание, что они существуют только относительно различных видов зависимостей атрибутов БД. Есть зависимости – нужно стоить НФ БД, нет зависимостей – БД и так находится в НФ. Но последний вариант практически не встречается в реальных приложениях.

Итак, какие же транзитивные и многозначные зависимости присутствуют в нашем примере БД менеджера турфирмы?

Давайте проанализируем отношение «Туристы». Рассмотрим зависимости между атрибутами «Код туриста», «Фамилия», «Имя», «Отчество» и «Паспорт» (рис. 3). Каждый турист, представленный в отношении сочетанием «Фамилия- Имя-Отчество», имеет на время поездки только один паспорт, при этом полные тезки должны иметь разные номера паспортов. Поэтому атрибуты «Фамилия- Имя-Отчество» и «Паспорт» образуют в отношении туристы составной ключ.

Составной ключ

Отчество

Код туриста

Рис. 3. Пример транзитивной зависимости

Как видно из рисунка, атрибут «Паспорт» транзитивно зависит от ключа «Код туриста». Поэтому, чтобы исключить данную транзитивную зависимость, разобьем составной ключ отношения и само отношение на 2 по связям «один-к-одному». В первое отношение, оставим ему имя «Туристы», включаются атрибуты «Код туриста» и «Фамилия», «Имя», «Отчество». Второе отношение, назовем его «Информация о туристах», образуют атрибуты «Код туриста» и все оставшиеся атрибуты отношения «Туристы»: «Паспорт», «Телефон», «Город», «Страна», «Индекс». Эти два новых отношения уже не имеют транзитивной зависимости и находятся в 3НФ.

Многозначные зависимости в нашей упрощенной БД отсутствуют. Для примера предположим, что для каждого туриста должны храниться несколько контактных телефонов (домашний, рабочий, сотовый и пр., что весьма характерно на практике), а не один, как в примере. Получаем многозначную зависимость ключа – «Код туриста» и атрибутов «Тип телефона» и «Телефон», в этой ситуации ключ перестает быть ключом. Что делать? Проблема решается также путем разбиения схемы отношения на 2 новые схемы. Одна из них должна представлять информацию о телефонах (отношение «Телефоны»), а вторая о туристах (отношение «Туристы»), которые связываются по полю «Код туриста». «Код туриста» в отношении «Туристы» будет первичным ключом, а в отношении «Телефоны» – внешним.

1.2.3. Физическая модель

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

и индексов.

В данном пособии будут рассмотрено создание физической модели БД средствами СУБД Microsoft Access и сервера баз данных Microsoft SQL Server 2005 Express Edition.

1.3. Создание БД в СУБД Microsoft Access

1.3.1. Таблицы

Для создания таблицы в СУБД Microsoft Access используем режим конструктора (рис. 4).

Рис. 4. Выбор режима конструктора

Рис. 5. Полный список полей таблицы

В появившемся окне «Таблица1: таблица» предстоит определить названия полей, которые и станут заголовками в этой таблице. Введем следующие названия полей (рис. 5).

При вводе названия поля, для него

по умолчанию определяется тип данных

«текстовый». Для изменения типа следу-

ет выбрать нужное значение из выпа-

дающего списка (рис. 6).

Рис. 6. Определение типа данных поля

Описания возможных типов дан-

ных Microsoft Access приводятся в таб-

Таблица 4

Типы данных Microsoft Access

Тип данных

Описание

Текстовый

Текст или комбинация текста и чисел, например, адреса, а также

числа, не требующие вычислений, например, номера телефонов, ин-

вентарные номера или почтовые индексы. Сохраняет до 255 знаков.

Свойство «Размер поля» (FieldSize) определяет максимальное коли-

чество знаков, которые можно ввести в поле

Поле МЕМО

Предназначено для ввода текстовой информации, по объему превы-

шающей 255 символов. Такое поле может содержать до 65 535 сим-

волов. Этот тип данных отличается от типа Текстовый (Text) тем, что

щиеся отдельно. За счет этого ускоряется обработка таблиц (сорти-

ровка, поиск и т. п.). Поле типа MEMO не может быть ключевым или

проиндексированным

Числовой

Данные, используемые для математических вычислений, за исклю-

чением финансовых

расчетов (для них следует использовать тип

«Денежный»). Сохраняет 1, 2, 4 или 8 байтов. Конкретный тип чи-

слового поля определяется значением свойства Размер поля (Field-

Дата/время

Значения дат и времени. Сохраняет 8 байтов

Денежный

Используется для денежных значений и для предотвращения округ-

ления во время вычислений. Сохраняет 8 байтов

Автоматическая вставка уникальных последовательных (увеличи-

вающихся на 1) или случайных чисел при добавлении записи. Со-

храняет 4 байта

Логический

Данные, принимающие только одно из двух возможных значений,

таких, как «Да/Нет», «Истина/Ложь», «Вкл./Выкл.». Значения Null не

допускаются. Сохраняет 1 бит.

Поле объекта

Объекты OLE (такие, как документы Microsoft Word, электронные

таблицы Microsoft Excel, рисунки, звукозапись или другие данные в

двоичном формате) (ограничивается объемом диска)

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

  • Анализ предметной области
  • Инфологическое (концептуальное) описание данных;
  • Логическое проектирование баз данных;
  • Физическое проектирование баз данных.

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

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

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

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

Существует два подхода к выбору состава и структуры предметной области:

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

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

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

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

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

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

Существует три основных типа отношений:

1) «один-к-одному». Такая связь означает, что каждому значению реквизита А соответствует одно и только одно значение связанного с ним реквизита В, и наоборот. Например, каждому значению реквизита Номер паспорта соответствует единственное значение реквизита ФИО гражданина страны, и наоборот. Такую связь обозначают 1:1, графически в инфологических моделях эта связь изображается одинарными стрелками.

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

3)«многие-ко-многим». Такая связь означает, что каждому значению реквизита А соответствует несколько значений связанного с ним реквизита В, и наоборот. Например, турагентство может работать с несколькими туроператорами, а туроператор обычно имеет разветвленную сеть турагентов. Такую связь обозначают М: М, а графически изображают двойными стрелками.

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

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

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

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

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

Файловая модель. Представляет собой совокупность не связанных между собой файлов из однотипных записей с линейной (одноуровневой) структурой.

Более сложными моделями внутримашинной организации данных являются сетевые и иерархические модели.

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

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

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

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

В каждой СУБД по -разному организованы хранение и доступ к данным. В системах баз данных файлы можно классифицировать следующим образом:

Файлы прямого доступа;

Файлы последовательного доступа;

Индексные файлы.


Похожая информация.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основные понятия о базах данных и СУБД

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

База данных – это ИС, которая хранится в электронном виде.

База данных (БД) – организованная совокупность данных, предназначенная для длительного хранения во внешней памяти ЭВМ, постоянного обновления и использования.

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

Классификация баз данных:

1. По характеру хранимой информации:

- Фактографические – содержат краткие сведения об описываемых объектах, представленных в строго определённом формате (картотеки, н-р: БД книжного фонда библиотеки, БД кадрового состава учреждения),

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

2. По способу хранения данных:

- Централизованные (хранятся на одном компьютере),

- Распределенные (используются в локальных и глобальных компьютерных сетях).

3. По структуре организации данных:

- Реляционные (табличные),

- Нереляционные.

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

Свойства реляционной модели данных:

Каждый элемент таблицы – один элемент данных;

Все поля таблицы являются однородными, т.е. имеют один тип;

Одинаковые записи в таблице отсутствуют;

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

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

Узел – информационная модель элемента, находящегося на данном уровне иерархии.

Свойства иерархической модели данных:

Несколько узлов низшего уровня связано только с одним узлом высшего уровня;

Иерархическое дерево имеет только одну вершину (корень), не подчинено никакой другой вершине;

Каждый узел имеет своё имя (идентификатор);

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

Иерархической базой данных является Каталог папок Windows, с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол. На втором уровне находятся папки Мой компьютер, Мои документы, Сетевое окружение и Корзина, которые представляют собой потомков папки Рабочий стол, будучи между собой близнецами. В свою очередь, папка Мой компьютер – предок по отношению к папкам третьего уровня, папкам дисков (Диск 3,5(А:), С:, D:, E:, F:) и системным папкам (Принтеры, Панель управления и др.).

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

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

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

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

Основные действия, которые пользователь может выполнять с помощью СУБД:

Создание структуры БД;

Заполнение БД информацией;

Изменение (редактирование) структуры и содержания БД;

Поиск информации в БД;

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

Защита БД;

Проверка целостности БД.

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

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

Популярные СУБД - FoxPro, Access for Windows, Paradox.

Таким образом, необходимо различать собственно базы данных (БД) – упорядоченные наборы данных, и системы управления базами данных (СУБД) – программы, управляющие хранением и обработкой данных. Например, приложение Access, входящее в офисный пакет программ Microsoft Office, является СУБД, позволяющей пользователю создавать и обрабатывать табличные базы данных.

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

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

- Минимальные затраты. Низкая стоимость хранения и использования данных, минимизация затрат на внесение изменений.

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

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



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

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

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

Далее на примере одной из самых распространенных систем управления базами данных – Microsoft Access входит в состав популярного пакета Microsoft Office – мы познакомимся с основными типами данных, способами создания баз данных и с приемами работы с базами данных.

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

Как и любой программный продукт, база данных обладает собственным жизненным циклом (ЖЦБД). Главной составляющей в жизненном цикле БД является создание единой базы данных и программ, необходимых для ее работы.

ЖЦБД включает в себя следующие основные этапы:

1. Планирование разработки базы данных;

2. Определение требований к системе;

3. Сбор и анализ требований пользователей:

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

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

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

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

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

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

5. Разработка приложений:

Проектирование транзакций (группа инструкций SQL (набор команд), исполняемых как единое целое);

Проектирование пользовательского интерфейса;

6. Реализация;

8. Тестирование;

9. Эксплуатация и сопровождение:

Анализ функционирования и поддержка исходного варианта БД;

Адаптация, модернизация и поддержка переработанных вариантов.

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

Основные задачи проектирования баз данных:

Обеспечение хранения в БД всей необходимой информации.

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

Сокращение избыточности и дублирования данных.

Обеспечение целостности базы данных.