Понятие предметной области

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

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

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

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

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

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

На этапе логического проектирования производится организация выделенных данных в форму, принятую в выбранной СУБД. Целью логического проектирования является преобразование концептуальной модели в логическую. Для реляционной БД этот этап состоит в разработке структуры объектов, определении связей между ними и выявлении ключевых реквизитов. Результат – построение диаграмм «сущность–связь» (EntityRelationship – ER-диаграмм). Далее для построения оптимальной структуры базы данных проводится процесс нормализации.

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

Основные понятия ER-диаграмм

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

Термины, которыми оперирует реляционная модель данных, имеют соответствующие «табличные» синонимы, представленные в таблице 1.

Таблица 1. Соответствие реляционных и табличных терминов

Определение 1. Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели.

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

Определение 2. Экземпляр сущности – это конкретный представитель данной сущности. Например, представителем сущности Преподаватель может быть Преподаватель Егоров.

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

Определение 3. Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности Преподаватель могут быть такие атрибуты как Табельный номер, Фамилия, Имя, Отчество, Должность, Зарплата и т. п.

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

Определение 5. Связь – это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею. Например, связи между сущностями могут выражаться следующими фразами – «ПРЕПОДАВАТЕЛЬ может вести несколько ПРЕДМЕТОВ», «каждый СТУДЕНТ обязан числиться ровно в одной ГРУППЕ».

Каждая связь может иметь один из следующих типов связи: «один-к-одному», «один-ко-многим» ими «многие-к-одному», «многие-ко-многим».

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