Структура и построение информационной модели предметной области

Процесс создания информационной модели начинается с определения концептуальных требований будущих пользователей БД (работники военной кафедры, деканатов и факультетов). На рис. 4 представлена общая структура информационной модели.

Видео: Синергия+UML HD

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

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

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

В настоящее время различают в основном три типа информационных моделей: иерархическую, сетевую и реляционную.

Иерархическая и сетевая модели данных стали применяться в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных, которая предназначалась в БД для ПК.

Эти три модели различаются в основном способами информационного отображения объектов и их взаимосвязей. Примем за базовую реляционную модель.

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

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

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

Такая единая база данных представляется идеальной для всех структурных подразделений военной кафедры, факультета.

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

При рассмотрении требований конечных пользователей к БД необходимо принимать во внимание следующее:

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

2. БД должна обеспечивать получение требуемых данных за приемлемое время, то есть обеспечивать заданную производительность.

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

4. База данных должна быть рассчитана на возможность расширения при реорганизации и расширении предметной области.

5. БД должна легко изменяться при изменении программной и аппаратной среды.

6. Загруженные в БД корректные данные должны оставаться корректными.

7. Данные до включения в БД должны проверяться на достоверность.

8. Доступ к данным, размещаемым в БД, должны иметь только лица с соответствующими полномочиями.

Этапы проектирования базы данных с учётом рассмотренных выше аспектов представлены на рис.5. В результате анализа поставленной задачи и

Рис.5.

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

Видео: WIAD 2017 SPb: Открытие. Максим Цепков "От монолитных моделей предметной области — к модульным"

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

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

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

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

Для получения требуемой модели необходимо учитывать связи военной кафедры с факультетами, кафедрами вуза.<< ПредыдушаяСледующая >>
Внимание, только СЕГОДНЯ!