Оглавление

Введение

1.Инфологическое проектирование

2. Задачи инфологического проектирования

Заключение

Список источников

Введение

При проектировании базы данных решаются три основных проблемы:

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

Каким образом отобразить объекты предметной области в абстрактные объекты модели данных так, чтобы это отображение не противоречило семантике предметной области, и было, по возможности, наилучшим (эффективным, удобным и т.д.)? Эта проблема известна как проблема логического проектирования баз данных. Цель логического этапа проектирования — организация данных, выделенных на предыдущем этапе, в форму, принятую в выбранной СУБД.

Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) необходимо потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных. Цель физического этапа — выбор рациональной структуры хранения данных и методов доступа к ним.

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

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

1.Инфологическое проектирование

Инфологическое проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

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

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

2. Задачи инфологического проектирования

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

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

Анализ ПО выполняется проектировщиком БД с помощью специалистов в данной ПО. В основе анализа лежат документы, используемые в работе предприятия (организации), и технология работы с данными.

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

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

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

• используемых методов анализа предметной области;
• правил именования и обозначения сущностей ПО, атрибутов и связей;
• содержания и формата создаваемых ими документов.

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

Выбор локального представления зависит от масштабов ПО. Обычно ПО разбивается на локальные области так, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей (т.е. объектов, о которых в системе будет накапливаться информация). Таким образом, если ПО небольшая, то разбиение на локальные представления не требуется и моделирование выполняется для ПО в целом.

Для каждой сущности определяются атрибуты (свойства), которые можно условно классифицировать следующим образом:

1. Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам сущности. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
2.  Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
3. Однозначные и многозначные атрибуты (могут иметь соответственно одно или много значений для каждого экземпляра сущности).
4. Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст человека вычисляется на основе даты его рождения и текущей даты).

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

Далее осуществляется спецификация связей. Под связью понимается осмысленная ассоциация между сущностями.

Кроме спецификации связей типа «сущность-сущность», выполняется спецификация связей типа «сущность-атрибут» и «атрибутатрибут» внутри одной сущности. Для этого надо определить зависимости между экземплярами сущностей и атрибутами, а также между атрибутами, относящимися к одному экземпляру сущности.

После выявления сущностей и связей ПО строят ER-диаграмму, которая является наглядным отображением модели ПО.

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

• объединение в единое целое фрагментарных представлений о различных свойствах одной и той же сущности;
• введение абстрактных понятий, удобных для решения задач системы, установление их связи с более конкретными понятиями модели;
• образование классов и подклассов подобных сущностей (например, класс «изделие» и подклассы типов изделий, производимых на предприятии).

При объединении локальных представлений используют три основополагающие концепции:

1. Идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение. Например, СОТРУДНИК для отдела кадров и СОТРУДНИК для отдела закупок — это один и тот же тип сущности, возможно, с разным набором атрибутов. (Наборы атрибутов исходных сущностей при этом объединяются.)
2. Агрегация. Позволяет рассматривать связь между элементами как новый элемент.
3. Обобщение. Позволяет образовывать многоуровневую иерархию обобщений.

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

По завершении объединения результаты проектирования представляют собой концептуальную инфологическую модель ПО. Она фиксируется в виде общей ER-диаграммы предметной области. Модели локальных представлений — это внешние инфологические модели (внешние схемы).

На этапе анализа ПО также решаются следующие задачи:

1. Определение правил (ограничений целостности), которым должны удовлетворять сущности ПО, атрибуты сущностей и связи между ними. Часть этих правил реализуется в схеме базы данных. Возможности реализации ограничений целостности в схеме БД определяются моделью данных той СУБД, которая будет выбрана для реализации проекта. Остальные правила реализуются с помощью программного обеспечения.
2. Выделение групп пользователей системы. Каждая группа выполняет определённые задачи и обладает разными правами доступа к системе.
3. Создание внешней спецификации тех функций (процессов), которые эта система будет выполнять. Например, для той же библиотечной системы это задачи поиска книг (по определённым критериям), выдачи/приёма книг, определение списка должников и т.д. Эта спецификация является основой для разработки приложений и выдаётся программистам в качестве задания.

Заключение

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

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

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

Список источников

Инфологическое моделирование базы данных [Электронный ресурс]. — URL:https://studbooks.net/2004292/informatika/infologicheskoe_modelirovanie_bazy_dannyh_abiturient_

Этапы проектирования базы данных [Электронный ресурс]. — URL: https://ami.nstu.ru/~vms/method2m/chapter_01.html?ysclid=ld0c1ya1f7914106639

Проектирование баз данных, его этапы и задачи [Электронный ресурс]. — URL: Проектирование баз данных, его этапы и задачи. [Реферат №5503] (evkova.org)

Инфологическое проектирование [Электронный ресурс]. — URL:https://ozlib.com/1057691/tehnika/infologicheskoe_proektirovanie?ysclid=ld0avyosbt458210088