Научный журнал

Вестник Алтайской академии экономики и права

Print ISSN 1818-4057

Online ISSN 2226-3977

Перечень ВАК

• Авторы
• Резюме
• Файлы
• Ключевые слова
• Литература

Гумерова Г.Р. 1 Бурханова Ю.Н. 2 Мансурова Т.Г. 3

---

1 ФБГОУ ВО «Казанский национальный исследовательский технический университет им. А.Н. Туполева – КАИ»

2 ФГБОУ ВО «Набережночелнинский государственный педагогический университет»

3 Набережночелнинский институт ФГАОУ ВО «Казанский (Приволжский) федеральный университет»

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

Статья в формате PDF

1976 KB

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

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

проектирование модели сущность-связь

проектирование инфологической модели

переход от модели сущность-связь к реляционной

1. Алиев Р.С. Проектирование базы данных и формализация данных для уменьшения трудозатрат в вузе // E-Scio. 2020. № 10(49). С. 179-186.

2. Бабанов А.М. Семантическая методика проектирования БД и ее перспективы, открывающиеся с применением ERM-модели данных // Вестник Томского государственного университета. Управление, вычислительная техника и информатика. 2011. № 3(16). С. 58-66.

3. Вигерс К., Битти Д. Разработка требований к программному обеспечению. 3-е изд., доп. / Пер. с англ. СПб.: БХВ, 2023. 736 с.

4. Горшков Д.А., Кутепова Л.А. Исследование современных методов проектирования базы данных // Успехи современного естествознания. 2011. № 7. С. 98-98.

5. Гумерова Г.Р., Мансурова Т.Г. Проектирование и разработка компонентов информационной системы образовательного учреждения на примере проекта автоматизации работы специалиста по научно-исследовательской работе. Курск: Университетская книга, 2022. 140 с. DOI 10.47581/2022/Gumerova.01.

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

Особенностью построения инфологической модели является то, что она позволяет описать данные и их связи без учета способа их хранения, отражая только семантические связи между объектами предметной области и их характеристики [2]. Описание проектируемых объектов должны быть понятны всем членам проектной команды, включая стейкхолдеров. Инструментарий систем управления базами данных (СУБД) должен эффективно обрабатывать запросы пользователей к базе данных, и поэтому крайне важно получить на выходе нормализованную, отвечающую правилам целостности, грамотно спроектированную информационно-логическую структуру базы данных.

Шаг 1. Анализ предметной области. Анализ предметной области позволяет выявить объекты сферы автоматизации, их свойства, характеристики, связи, особенности функционирования, а также возможные «узкие» проблемные места. Предметная область рассматривается как система с множеством взаимосвязанных элементов и роль системного аналитика определить значимые элементы, роль каждого из них и сформулировать функциональные и нефункциональные требования к разрабатываемой системе. Анализ предметной области также дает ответ на вопрос о возможности удовлетворения требований заказчика. В результате анализа предметной области осуществляется ее декомпозиция и формируется перечень сущностей. Некоторые сущности могут быть выделены исключительно на интуитивном уровне, но тем не менее все сущности проблемной области представлены двумя группами отображаемой информации – сущности-объекты и сущности-события, и выделяются согласно следующим правилам.

1. Если сущность характеризует название, новые записи вводятся нечасто, то это сущность-объект. Сущности-объекты соответствуют нормативно-справочной информации в автоматизированной информационной системе (АИС), для них по умолчанию определены код и наименование. Например, сущность-объект «Товар», записи в данный объект, как-правило, вводятся на этапе опытной эксплуатации информационной системы и новые добавляются эпизодически, по мере расширения товаров в номенклатуре. Для объекта определяется его название и код наименования.

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

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

Таблица 1

Фрагмент таблицы описания сущностей предметной области

Фрагмент рекомендованного описания сущностей предметной области «Централизованная библиотечная система» представлен в табл. 1.

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

Анализ предметной области «Централизованная библиотечная система» выявил следующие сущности: сущности-объекты (Издания, Читатель, Издательство, Жанр, Библиотекарь, Филиал, Мероприятие, Библиотечное объединение, Состав библиотечных объединений), сущности-события (Библиотечная карточка, Проведение мероприятий, Встречи библиотечных объединений).

Шаг 2. Определить свойства сущностей. Следующим шагом построения инфологической модели является определение атрибутов каждой сущности. Атрибут сущности (свойство сущности) – это любая, значимая для предметной области характеристика сущности, предназначенная для идентификации или количественной характеристики сущности [2]. Для свойства сущности дают их описание, определяют тип, ключевые элементы, размерность, допустимые значения и связь с другой сущностью, в случае если атрибут представляет собой ссылку на атрибут другой сущности. В целях обеспечения целостности базы данных рекомендуется отдавать предпочтение выделению простых атрибутов, представляющим собой атомарные значения, нежели составных. При описании предметной области выделять производные атрибуты, являющиеся расчетными, значения которых получены из других атрибутов, но в последствии такие атрибуты в физической базе данных существовать не будут и для них соответствующий реквизит в реляционной модели создается. В связи с тем, что значение подобного атрибута возможно получить в результате расчетов других атрибутов и место в базе данных для него не резервируется.

В табл. 2 представлен фрагмент описания атрибутов сущности предметной области «Централизованная библиотечная система».

Шаг 3. Выявить связи между сущностями и дать их характеристику. Далее определяется характер взаимосвязи ассоциация, установленный между несколькими сущностями. Связь обладает именем, степенью (мощностью) и классом принадлежности. Инфологическая модель, в отличие от реляционной, допускает наличие связей 1:1, 1:М, М:1, М:N. Класс принадлежности характеризует обязательный или необязательный характер связи между экземплярами двух сущностей. Согласно методологии проектирования моделей данных есть правило, согласно которому связи обозначаются глагольными формами. В табл. 3 представлен фрагмент связей сущностей предметной области «Централизованная библиотечная система».

Таблица 2

Фрагмент таблицы описания атрибутов сущностей

Таблица 3

Фрагмент таблицы описания связей сущностей

Рис. 1. Связь «содержит» между сущностями «Издания» и «Библиотечная карточка»

Каждое издание может содержаться во многих библиотечных карточках или ни в одной, при этом также конкретная библиотечная карточка может содержать много изданий или ни одного. Таким образом, не каждая библиотечная карточка может быть заполнена конкретным изданием. В связи с этим класс принадлежности в связи у сущностей «Издания» и «Библиотечная карточка» необязательный.

Шаг 4. Построение ER-модели предметной области. В результате анализа предметной области определен набор сущностей-объектов и сущностей-событий, отражающих предметную область (табл. 1-3), их атрибуты и связи между сущностями. Теперь необходимо их визуализировать, построив ER- модель. Для построения модели сущность связь можно выбрать нотацию Чена, UML, IDEF1X, «Воронья лапка» и т.д. [18].

Рис. 2. Модель сущность-связь предметной области «Централизованная библиотечная система» в нотации «Воронья лапка»

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

Шаг 5. Преобразовать ER-модель в реляционную модель базы данных. Инфологическая модель данных, созданная на предыдущем шаге, уточняется и преобразуется в логическую модель данных, которая учитывает особенности выбранной модели организации данных в СУБД, например, реляционная модель [5]. Последняя является наиболее распространенной и используется в большинстве современных систем. Правила перехода от инфологической модели к реляционной модели базы данных предусматривают создание отношений, которые содержат данные и связи между ними. Это обеспечивает эффективную организацию информации и быстрого доступа к ней. При проектировании реляционных баз данных необходимо учитывать множество факторов, таких как размер и сложность данных, требования к производительности и безопасности, что делает этот процесс достаточно сложным и ответственным.

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

Рис. 3. Логика определения количества отношений в БД при переходе от инфологической модели

Логика перехода от инфологической модели к реляционной отображена на рис. 3. В первую очередь необходимо определиться с типом связи – бинарная или тернарная. Если связь тернарная, то не имеет значение мощность связи и для хранения таких данных необходимо четыре отношения – три отношения выделенные на основе сущностей и одно отношение на основе связи. При этом класс принадлежности сущностей не будет иметь значения. Все формируемые связи будут типа 1:М. В проектируемой предметной области существует тернарная связь «Проведение мероприятий» между сущностями «Библиотекарь», «Филиал», «Мероприятие» (рис. 2). После преобразования получено четыре отношения «Библиотекарь», «Филиал», «Мероприятие» и «Проведение мероприятий» между которыми связи 1:М (рис. 4).

В отличие от тернарной связи для бинарной имеет значение мощность связи и класс принадлежности сущности в связи. Для бинарной связи 1:1, где класс принадлежности обеих сущностей обязательный, для такой связи в реляционной модели будет выделено одно отношение. Первичный ключ, полученного отношения, может быть выбран любой из первичных ключей этих двух сущностей. Для проектируемой предметной области такой связью является связь между сущностями «Читатель» и «Библиотечная карточка» (рис. 2), и после преобразования будет выделено одно отношение – «Библиотечная карточка», которое включает атрибуты обеих сущностей, а первичным ключом является реквизит «Номер библиотечной карточки» (рис. 4).

Когда мощность бинарной связи 1:1, но у одной из сущностей необязательное участи в связи, то в реляционной модели образуются два отношения. Для сущности, у которой степень участия необязательная, ключевой реквизит добавляется как внешний ключ в сущность с обязательным участием.

Три отношения выделяется для связи 1:1 у которой класс принадлежности обеих сущностей необязательный. Два отношения реализуются на основе сущностей и содержат первичные ключи, а третье выделяется из связи, которое включает внешние ключи от этих двух отношений. В предметной области «Централизованная библиотечная система» такой связью является связь сущностей «Мероприятие» и «Филиал» (рис. 2). Каждое конкретное мероприятие может проводится только одним филиалом или не проводится вообще, каждый филиал может проводить или не проводить какое-то одно мероприятие. Каждое проведенное мероприятие уникально и не повторяется более чем один раз. Класс принадлежности обеих сущностей необязательный, так как филиал может и не проводить какое-либо мероприятие, поэтому будет сформировано три отношения «Мероприятие», «Филиал» и «Проведение мероприятий», со связями 1:1. Отношение «Проведение мероприятий» содержит внешний ключ реквизитов «Номер филиала» и «Номер мероприятия» (рис. 4).

Для связи 1:М в которой класс участи сущности с множественной связью обязательный создается два отношения. В анализируемой предметной области такой связью является связь «Жанр» и «Издания» (рис. 2).

Рис. 4. Логическая структура базы данных предметной области «Централизованная библиотечная система»

Конкретный жанр должен соответствовать одному или нескольким изданиям и каждое издание должно соответствовать какому-то конкретному жанру. Конкретный жанр соответствует конкретному изданию, поэтому сущности «Издания» обязательно должна соответствовать сущность «Жанр». Также каждое издание должно соответствовать какому-то конкретному жанру, в такой связи каждый экземпляр сущности «Жанр» имеет ассоциированный с ней экземпляр сущности «Издания», таким образом, каждый экземпляр сущности принимает участие в связи «Соответствует». Поэтому класс принадлежности в связи между сущностями «Жанр» и «Издания» обязательный и в таком случае будет создано два отношения в реляционной модели со связью 1:М (рис. 4).

Когда связь 1:М, а класс принадлежности сущности с множественной связью необязательный, то создается три отношения. В рассматриваемом проекте в качестве примера такой связи можно выделить связь «Состоит в» между сущностями «Библиотечное объединение» и «Читатель». В конкретное библиотечное объединение должен входить один или множество читателей, в противном случае иначе библиотечное объединение будет расформировано. Конкретный читатель может входить только в одно объединение или ни в одного. Для такой связи будет создано три отношения: «Библиотечное объединение», «Читатель», «Состав библиотечного объединения», где отношение «Состав библиотечного объединения» подчиненное, и включает внешние ключи от отношений-родителей. Связи между отношениями, следующие: «Читатель» и «Состав библиотечного объединения» 1:1, в связи с тем, что читатель может входить только в одно объединение, а «Библиотечное объединение» и «Состав библиотечного объединения» связь 1:М, так как в каждое библиотечное объединение входят от одного до множестве читателей (рис. 4).

Для связи М:N класс принадлежности сущности значения не имеет и для хранения данных необходимо три отношения – два отношения, выделенные из сущностей и одно отношение из связи. В виду того, что в реляционной модели не должно присутствовать связей М:N, то ее необходимо преобразоваться в две связи 1:М. В моделируемой предметной области данной связи соответствует связь между сущностями «Издания» и «Библиотечная карточка» (рис. 2), будет создано три отношения «Издания», «Библиотечная карточка» и «Вкладыш библиотечной карточки». Связь М:N была преобразована в связи «Издания» – «Вкладыш библиотечной карточки» и Библиотечная карточка» – «Вкладыш библиотечной карточки» (рис. 4).

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

Шаг 6. Определить состав атрибутов отношений. Для полученных отношений определить состав атрибутов, распределить их на описательные и ключевые реквизиты, определить вид ключа (простой, составной, внешний). Распределив атрибуты по полученным отношениям, получим состав атрибутов каждого отношения. В табл. 4 представлен фрагмент описания атрибутов для отношения.

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

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

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

Таблица 4

Фрагмент таблицы описания атрибутов отношений

Таблица 5

Фрагмент таблицы описания связей между отношениями

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

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

В табл. 6 представлен фрагмент описания свойств реквизитов предметной области «Централизованная библиотечная система» для отношения «Жанр» (табл.6).

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

Таблица 6

Фрагмент таблицы описания реквизитного состава отношения «Жанр»

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

Библиографическая ссылка