О С Н О В Ы П О С Т Р О Е Н И Я Б А Н К О В
Д А Н Н Ы Х
Соответственно двум понятиям - “информация” и “данные” - в банках данных различают два аспекта рассмотрения вопросов: инфологический и датологический
.Инфологический аспект употребляется в связи со смысловым содержанием данных независимо от способов их представления в памяти системы. На этапе инфологического проектирования ИС далее решаются вопросы:
Т.о. на этапе инфологического проектирования выделяется часть реального мира, определяющая информационные потребности системы, т.е. ее предметная область (ПО).
Датологический аспект употребляется в связи с необходимостью представления данных в памяти ИС.
Датологическое проектирование ИС предусматривает разработку соответствующих форм представления информации в системе посредством данных, исходя из возможностей имеющихся систем восприятия, хранения и обработки информации. Приводятся модели и методы представления и преобразования данных, формулируются правила смысловой интерпретации данных.
Данные (д) соответствуют зарегистрированным фактам об объектах или явлениях реального мира. Чтобы в дальнейшем использовать д., требуется их смысловое содержание - семантика д. Поэтому в ИС должны быть сформулированы правила смысловой интерпретации д.
АРХИТЕКТУРА БнД.
Для обеспечения независимости ПП от сведений о способах и деталях представления д. и методов доступа к ним вводится
модель д., которая отражает для пользователей только информационное содержание БД без подробностей организации физического хранения д. Модель имеет свою схему, в которой отражается структура ее д., имена записей и форматы полей. ЯОД и ЯМД разрабатываются для работы с данными модели. ПП работает с записями модели (т.е. логический уровень).АБД задает специальное описание необходимого отображения хранимых в базе д. в данные модели. СУБД реализует отображение (прямое и обратное):
Модель ---- хранимая БД
В описании отображения, кроме указания соответствий между полями записей модели и полями хранимых записей, указываются все необходимые сведения о хранимых д.: в каком коде они представлены, как они упорядочены, какие существуют индексы, где расположены те или иные д., с какими данными они связаны, какие методы доступа необходимо использовать для манипулирования хранимыми д. и т.п.
Часть задач обработки д. целесообразно возложить на ОС, используя ее программы методов доступа. Т.о. обеспечивается относительная независимость операций хранения д от используемых технических средств. Т.е. вводится понятие внутренней модели БД:
Модель ---- Внутренняя модель ---- физическая БД
При проектировании СУБД разрабатываются собственные методы доступа к хранимым записям (внутренней модели), базирующиеся на методах доступа ОС. Во внутренней модели БД должна быть представлена в виде совокупности хранимых файлов, для которых известна структура хранимых записей, определены служебные поля, реализующие необходимые связи между записями, известны методы доступа СУБД к этим записям и т.д. В состав СУБД включаются средства преобразования хранимых записей к виду физического представления на машинном носителе и обратно.
Эта схема решает вопрос независимости ПП от д., однако требует знания модели д. пользователем, что не всегда оправдано. Следовательно, необходимо внешнее представление д. Логическое представление в МД является “синхронизирующим”, сама модель - концептуальной моделью.
Между внешней и концептуальной моделями также должно быть реализовано отображение.
СУБД реализует отображения:
ВМД ---- КМД ---- ВнМД ---- ФБД.
Количество ВМД определяется числом ПП.
Наличие в БнД процессов обмена информации между пользователями и системой, между АБД и системой, а также между моделями д. различных уровней ставит вопрос об унификации этих процессов, т.е. о разработке соответствующих интерфейсов.
В настоящее время для многопользовательских ИС получил наибольшее распространение трехуровневый подход к построению БнД, включающий внешний (пользовательский, локальный), концептуальный (глобальный) и внутренний уровни.
При таком подходе на внешнем уровне поддерживаются ограниченные модели ПО, видимые отдельными приложениями (пользователями). На концептуальном уровне поддерживается модель ПО для всех приложений. Уровень хранимых данных - внутренний уровень. Такая архитектура БнД придает ему способность к адаптации к возможным изменениям как в ПП, так и в самих д.
Объекты во внешних моделях (“внешние” записи) создаются при реализации приложений по требованию последних и перестают существовать, когда отпадает необходимость в этих объектах. Объекты во внутренней модели (“внутренние“ записи) содержат хранимые данные, использующиеся для формирования записей концептуальной и внешней моделей. КС может содержать описания объектов (концептуальные записи).
Процесс проектирования БД представляется последовательностью проектирования моделей данных соответствующих уровней абстрагирования. Основные уровни абстрагирования в БнД - внешний, концептуальный, внутренний и предшествующий им - инфологический (информационный). В процессе проектирования БД разрабатываются схемы моделей каждого уровня, проверяется возможность отображения объектов одной модели объектам другой модели.
Основные этапы проектирования БД:
- инфологическое проектирование;
- датологическое проектирование.
Задача инфологического этапа проектирования: получение семантических (смысловых) моделей д., отображающих информационное содержание конкретной ПО. Вначале выполняется выделение из воспринимаемой реальности требуемой части ПО, определяются ее границы, происходит абстрагирование от несущественных частей для конкретного применения БнД. В результате определяются объекты, их свойства и связи, которые будут существенны для будущих пользователей системы.
После этого происходит процесс изучения ПО, накопление знаний о ней (в какой-то языковой системе).
Выполняется структуризация знаний ПО: выделяются и классифицируются множества составляющих ПО, стандартизируется терминология.
Выполняется формирование описаний внешних инфологических моделей, их взаимная увязка с концептуальной инфологической моделью.
Концептуальная инфологическая модель призвана обеспечить прочную и долговременную работу всей системы. Эта модель должна выдерживать замену одной используемой СУБД на другую.
Задачей датологического этапа проектирования является выбор конкретной СУБД, рациональной структуры хранения д. и методов доступа к ним, исходя из того арсенала средств и методов, который предоставляется разработчику СУБД.
Литература и источники
1. Ревунков Г.И., Самохвалов Э.Н., Чистов В.В. Базы и банки данных и знаний. - М., Высш. шк., !992, с. 367.