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

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

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

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

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

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

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

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

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

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

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

• 1. Определение цели создания базы данных На первом этапе проектирования базы данных необходимо определить цель создания базы данных, основные ее функции и информацию, которую она должна содержать. То есть нужно определить основные темы таблиц базы данных и информацию, которую будут содержать поля таблиц. База данных должна отвечать требованиям тех, кто будет непосредственно с ней работать. Для этого нужно определить темы, которые должна покрывать база данных, отчеты, которые она должна выдавать, проанализировать формы, которые в настоящий момент используются для записи данных, сравнить создаваемую базу данных с хорошо спроектированной, подобной ей базой.
• 2. Определение таблиц, которые должна содержать база данных. Одним из наиболее сложных этапов в процессе проектирования базы данных является разработка таблиц, так как результаты, которые должна выдавать база данных (отчеты, выходные формы и др.) не всегда дают полное представление о структуре таблицы. При проектировании таблиц вовсе не обязательно использовать Microsoft Access. Сначала лучше разработать структуру на бумаге. При проектировке таблиц, рекомендуется руководствоваться следующими основными принципами:
  • o Информация в таблице не должна дублироваться. Не должно быть повторений и между таблицами. Когда определенная информация храниться только в одной таблице, то и изменять ее придется только в одном месте. Это делает работу более эффективной, а также исключает возможность несовпадения информации в разных таблицах. Например, в одной таблице должны содержаться адреса и телефоны клиентов.
  • o Каждая таблица должна содержать информацию только на одну тему.

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

• 3. Определение необходимых в таблице полей. Каждая таблица содержит информацию на отдельную тему, а каждое поле в таблице содержит отдельные сведения по теме таблицы. Например, в таблице с данными о клиенте могут содержаться поля с названием компании, адресом, городом, страной и номером телефона. При разработке полей для каждой таблицы необходимо помнить:
  • o Каждое поле должно быть связано с темой таблицы.
  • o Не рекомендуется включать в таблицу данные, которые являются результатом выражения.
  • o В таблице должна присутствовать вся необходимая информация.
  • o Информацию следует разбивать на наименьшие логические единицы (Например, поля «Имя» и «Фамилия», а не общее поле «Имя»).
• 4. Задание индивидуального значения каждому полю с тем чтобы Microsoft Access мог связать данные из разных таблиц, например, данные о клиенте и его заказы, каждая таблица должна содержать поле или набор полей, которые будут задавать индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют основным ключом.
• 5. Определение связей между таблицами. После распределения данных по таблицам и определения ключевых полей необходимо выбрать схему для связи данных в разных таблицах. Для этого нужно определить связи между таблицами.
• 6. Обновление структуры базы данных. После проектирования таблиц, полей и связей необходимо еще раз просмотреть структуру базы данных и выявить возможные недочеты. Желательно это сделать на данном этапе, пока таблицы не заполнены данными. Для проверки необходимо создать несколько таблиц, определить связи между ними и ввести несколько записей в каждую таблицу, затем посмотреть, отвечает ли база данных поставленным требованиям. Рекомендуется также создать черновые выходные формы и отчеты и проверить, выдают ли они требуемую информацию. Кроме того, необходимо исключить из таблиц все возможные повторения данных.
• 7. Добавление данных и создание других объектов базы данных. Если структуры таблиц отвечают поставленным требованиям, то можно вводить все данные. Затем можно создавать любые запросы, формы, отчеты, макросы и модули.
• 8. Использование средств анализа в Microsoft Access. В Microsoft Access существует два инструмента для усовершенствования структуры баз данных. Мастер анализа таблиц исследует таблицу, в случае необходимости предлагает новую ее структуру и связи, а также переделывает ее. Анализатор быстродействия исследует всю базу данных, дает рекомендации по ее улучшению, а также осуществляет их.

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

• · максимально упрощает взаимодействие с базой данных;
• · гарантирует непротиворечивость данных;
• · «выжимает» максимум производительности из системы.

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

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

«Плохая структура» базы данных:

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

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

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

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

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