Главная | Обратная связь

Управление структурами хранения базы данных

3. Проектирование БД. Проблемы проектирования БД

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

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

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

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

При проектировании структур данных для автоматизированных систем можно выделить 3 подхода:

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

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

Структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности правил и рекомендаций.

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

При проектировании базы данных решаются две основных проблемы:

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

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

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

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

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

4. Процедуры концептуального проектирования

Цель этапа концептуального проектирования - создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур. Определение сущностей и их документирование. Для идентификации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваивается осмыс­ленное имя, понятное пользователям. Имена и описания сущностей заносятся в словарь данных. Если возможно, то устанавливается ожидаемое количество эк­земпляров каждой сущности. Определение связей между сущностями и их документирование. Определяются только те связи между сущностями, которые необходимы для удовлетворения требований к проекту базы данных. Устанавливается тип каж­дой из них. Выявляется класс принадлежности сущностей. Связям присваива­ются осмысленные имена, выраженные глаголами. Развернутое описание каж­дой связи с указанием ее типа и класса принадлежности сущностей, участвую­щих в связи, заносится в словарь данных. Создание ER-модели предметной области. Для представления сущ­ностей и связей между ними используются ER-диаграммы. На их основе созда­ется единый наглядный образ моделируемой предметной области - ER-модель предметной области. Определение атрибутов и их документирование. Выявляются все ат­рибуты, описывающие сущности созданной ER-модели. Каждому атрибуту присваивается осмысленное имя, понятное пользователям. О каждом атрибуте в словарь данных помещаются следующие сведения: имя атрибута и его описание; тип и размерность значений; значение, принимаемое для атрибута по умолчанию (если такое имеется); может ли атрибут иметь Null-значения; является ли атрибут составным, и если это так, то из каких простых атрибу­тов он состоит. Например, атрибут "Ф.И.О. клиента" может состоять из про­стых атрибутов "Фамилия", "Имя", "Отчество", а может быть простым, содер­жащим единые значения, как-то "Сидорский Евгений Михайлович". Если поль­зователь не нуждается в доступе к отдельным элементам "Ф.И.О.", то атрибут представляется как простой; • является ли атрибут расчетным, и если это так, то как вычисляются его зна­чения. Определение значений атрибутов и их документирование. Для каж­дого атрибута сущности, участвующей в ER-модели, определяется набор до­пустимых значений и ему присваивается имя. Например, атрибут "Тип счета" может иметь только значения "депозитный", "текущий", "до востребования", "карт-счет". Обновляются записи словаря данных, относящиеся к атрибутам, -в них заносятся имена наборов значений атрибутов. Определение первичных ключей для сущностей и их документиро­вание. На этом шаге руководствуются определением первичного ключа - как атрибута или набора атрибутов сущности, позволяющего уникальным образом идентифицировать ее экземпляры. Сведения о первичных ключах помещаются в словарь данных. Обсуждение концептуальной модели данных с конечными пользо­вателями. Концептуальная модель данных представляется ER-моделью с со­проводительной документацией, содержащей описание разработанной модели данных. Если будут обнаружены несоответствия предметной области, то в мо­дель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления.

5. Система управления базами данных

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

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

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

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

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

Для вывода в отчеты определенных данных применяются запросы (queries). Использование запросов похоже на процесс поиска, – задаются конкретные критерии отбора, на основе которых база данных формирует и возвращает отчет. Например, если база данных содержит информацию о телефонных номерах, то можно запросить вывести в отчете только те телефоны, которые относятся к конкретному адресу, или только те, которые относятся к конкретной фамилии, или начинающиеся с определенных цифр и т.п. Запросы записываются на языке SQL (Structured Query Language — язык структурированных запросов).

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