16

«Основные принципы проектирования банков данных фактографических АИС. Понятие информационно-логической схемы предметной области, схемы базы данных, внутренней схемы базы данных»

Введение

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

Фактографическая АИС, например, накапливают сведения по лицам, при этом каждому лицу соответствует запись, составленная из определённого набора реквизитов.

Одной из наиболее трудоемких и сложных задач при со­здании АИС является проектирование банка данных как осно­вы подсистемы представления и обработки информации. Ло­гическая и физическая структуры банка данных отражают пред­ставление разработчиками и пользователями информационной системы той предметной области, сведения о которой предпо­лагается отражать и использовать в АИС.

Основные принципы проектирования банков данных фактографических аис

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

В организационном плане в группе разработчиков банка данных выделяют специалистов по формализации предметной области, специалистов по программному обеспечению СУБД, а также технических дизайнеров и специалистов по эргономи­ке. Специалисты no формализации предметной области (их еще называют формализаторами или постановщиками задач), как правило, возглавляют весь проект создания АИС и обеспечива­ют функции взaимодейcтвия с заказчиком. К данной категории специалистов предъявляются наиболее сложные профессио­нальные требования. С одной стороны, такие работники долж­ны быть специалистами в сфере программного обеспечения АИС (операционные системы, СУБД и т. д.), а с другой сторо­ны, они должны хорошо представлять (или освоить) конкрет­ную предметную область АИС, т. е. быть (временно стать) бухгалтерами, экономистами, делопроизводителями и т.п. Спе­циалисты по программному обеспечению СУБД относятся к категории профессиональных программистов, определяют вы­бор СУБД и обеспечивают построение ее средствами автома­тизированного банка данных по разработанной постановщиком задачи (формализатором) концептуальной схеме. Технические дизайнеры и cneциaлисты по эргономике обеспечивают эсте­тичную и эргономичную сторону интерфейса с пользователем в АИС при вводе, обработке и поиске данных.

Этапы концептуального проектирования:

1 этап: обзор и изучение области использования для формирования общего предоставления предметной области. На этом этапе осуществляется изучение предметной области разработчиком в непосредственном взаимодействии с заказчиком.

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

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

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

Оригинальные предложения П. Чена по графическому обо­значению в диаграммах Бахмана сущностей и связей претерпе­ли изменения. Сейчас на ER - диаграмме объекты-сущности изображают прямоугольной (иногда с атрибутами) а связи – линиями с соответствующими символами. Возможны различные варианты связи: один к одному; один ко многим; многие ко многим.

Формализованное описание концептуальной схемы БД осуществляется на бумаге и служит основой эскизного проекта.

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

Схемно-структурное проектирование

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

Схемой БД называется логическая структура данных.

Проектирование схемы реляционной БД:

1. определение перечня таблиц;

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

3. разработка списков (словарей) для полей с перечислительным характером значений данных;

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

Вместе с тем современные СУБД могут предоставлять и более развитые возможности установления ограничений цело­стности данных. Можно определять допустимые диапазоны зна­чений полей (например, значение поля «Оклад» не может быть меньше величины минимального размера оплаты труда).

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

С формальной точки зрения нормализацию можно пред­ставить как последовательный процесс разбиения и преобра­зования некоторого небольшого исходного набора таблиц для построения набора взаимосвязанных таблиц в нормальных фор­мах. Основатель реляционной модели данных Е. Кодд выделял три нормальные формы — первую, вторую и третью. Этот на­бор в дальнейшем был дополнен нормальной формой Бойса-Кодда, и далее четвертой и пятой нормальными формами.

Результатом проектирования и нормализации таблиц явля­ется законченная схема (логическая структура) базы данных. Технологически описание схемы базы данных помещается в каталог базы данных, который в реляционных СУБД, в свою очередь, представляет также таблицу, структура (поля) кото­рой описывает объекты базы данных (таблицы), их названия, поля, параметры и т. д. Обычно каталог базы данных хранится в файле БД вместе с данными. В определенных случаях (системы «Клиент-сервер», распределенные системы, системы на основе репликации) может устанавливаться специальный ре­жим размещения и доступа к каталогу базы данных.

Для повышения эффективности схемно-структурного про­ектирования банков данных на рынке программных средств СУБД появился специальный класс программ, называемых CASE – системами (системы автоматизированного проек­тирования). Наиболее известными из них являются Designer 2000 компании «Оrасlе», ErWin компании «LogicWorks», PowerBulder компании «PowerSoft». Такие системы предостав­ляют проектировщику банка данных средства концептуально­го проектирования баз данных на основе техники семантичес­кого моделирования. При этом широко используются средства визуализации определения и описания информационных объек­тов, связей и их атрибутов, что делает процесс проектирования максимально наглядным и позволяет проектировщику сосре­доточиваться на смысловом аспекте структуры банка данных. Разработанная таким образом концептуальная схема банка дан­ных транслируется CASE-системой в схему соответствующе­го реляционного банка, избавляя проектировщика от утомитель­ных процедур «ручного» перевода концептуальной (семанти­ческой) схемы в реляционную.