Инфологическое проектирование баз данных

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

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

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

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

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

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

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

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

Основная роль атрибута – описание свойств сущности и идентификация экземпляров сущностей.

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

Типы связи: один ко многим, многие к одному, многие ко многим, один к одному.

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

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

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

Датологическое проектирование.

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

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

• поле – наименьшая поимённая единица

• запись – поименованная совокупность полей

• файл – поименованная совокупность экземпляров записей одного типа

• набор файлов (библиотека) – поименованная совокупность файлов, обрабатываемых в системе.

Элемент данных – наименьшая поименованная единица данных, к которой СУДБ может адресоваться непосредственно и с помощью которой выполняется построение всех остальных структур.

Агрегат данных – поименованная совокупность элементов данных внутри записи, которую можно рассматривать как единое целое.

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

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

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

Основные операции над данными.

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

По характеру проводимого действия различают следующие виды операций:

• идентификация данного и нахождение его позиции в БД

• выборка (чтение) данного из БД

• включение (запись) данного в БД

• удаление данного из БД

• модификация (изменение) данного в БД

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

S(t₁) -> S(t₂) -> … -> S(t_i) -> … S(t_j) -> …S(t_m)

Различаются внутренние и явные ограничения целостности. Внутренние ограничения целостности представлены МД правилами композиции допустимых структур данных и в конкретной схеме БД находят своё отражение в

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

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