МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ И СОЗДАНИЯ БАЗ ДАННЫХ ДЛЯ СОВРЕМЕННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

АННОТАЦИЯ

Задачей проектирования базы данных является адекватное отражение сути предметной области внутри базы данных с целью автоматизации. В теории баз данных применяются различные методы разработки моделей баз данных, которые охватывают разные аспекты ее архитектуры. Существуют два основных подхода: "нисходящий" и "восходящий". Также существует "смешанный подход", в котором комбинируются методы "восходящего" и "нисходящего" проектирования. Сначала используются "восходящие" и "нисходящие" методы для различных частей модели, затем собранные фрагменты интегрируются в цельную структуру. При создании собственных баз данных рекомендуется придерживаться правил проектирования баз данных. Это обеспечит долгосрочную целостность данных и упростит обслуживание информации. Руководство, представленное здесь, поможет вам понять сущность баз данных и научит, как спроектировать базу данных в соответствии с принципами реляционных баз данных. Базы данных представляют собой программы, предназначенные для хранения и получения больших объемов взаимосвязанной информации. Они организованы в виде таблиц, содержащих разнообразные данные. При создании базы данных необходимо тщательно продумать, какие таблицы следует включать и какие связи существуют между данными в этих таблицах. Другими словами, требуется подробное проектирование вашей базы данных. Эффективный проект базы данных обеспечит целостность информации и упростит ее обслуживание в долгосрочной перспективе. Целью при написании статьи стало исследование методологии проектирования и создания баз данных для современного программного обеспечивания. Методологией выступили научные труды, специальная литература и мнения экспертов.

ABSTRACT

The task of database design is to adequately reflect the essence of the subject area within the database for the purpose of automation. Database theory uses various methods of developing database models that cover different aspects of its architecture. There are two main approaches: "descending" and "ascending". There is also a "mixed approach", which combines the methods of "bottom-up" and "top-down" design. First, "ascending" and "descending" methods are used for various parts of the model, then the collected fragments are integrated into the whole structure. When creating your own databases, it is recommended to adhere to the rules of database design. This will ensure long-term data integrity and simplify the maintenance of information. The guide presented here will help you understand the essence of databases and teach you how to design a database in accordance with the principles of relational databases. Databases are programs designed to store and retrieve large amounts of interconnected information. They are organized in the form of tables containing a variety of data. When creating a database, you need to think carefully about which tables should be included and what relationships exist between the data in these tables. In other words, a detailed design of your database is required. An effective database project will ensure the integrity of the information and simplify its maintenance in the long term. The purpose of writing the article was to study the methodology of designing and creating databases for modern software. The methodology was scientific works, special literature and expert opinions.

Ключевые слова: базы данных, методология проектирования баз данных, программное обеспечение, ПО, создание баз данных.

Keywords: databases, database design methodology, software, software, database creation.

Введение

Существует два основных направления в проектировании баз данных: нисходящий и восходящий подходы (рис. 1). В восходящем подходе исследуется самый низкий уровень атрибутов - свойства сущностей и их взаимосвязи, которые анализируются и группируются в отношения, представляющие типы сущностей и связей.

Рисунок 1. Проектирование баз данных

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

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

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

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

Физическое проектирование базы данных - это подготовка описания реализации базы данных на вторичных носителях информации. На этом этапе рассматриваются вопросы организации файлов, индексов для обеспечения быстрого доступа к данным, а также внедрение ограничений целостности и мер безопасности данных. Важно учесть, что каждый из этих этапов играет ключевую роль в обеспечении эффективности и надежности базы данных в процессе ее использования [5].

1. Проектирование баз данных

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

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

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

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

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

Появление систем CASE (Computer Aided System Engineering) способствовало развитию структурного проектирования БД и связанных с ними информационных систем. Эти системы ориентированы на модели данных, поддерживаемые различными системами управления базами данных (СУБД). Наибольшей популярностью пользовались CASE-системы для реляционных СУБД с SQL-моделями данных, и интегрированный словарь данных (DD/D) был переименован в CASE-репозиторий проектируемых информационных систем.

Развитие CASE-систем и технологий проектирования привело к двум основным направлениям: CASE-системы для проектирования БД (или "верхний уровень") и интегрированные инструменты, которые позволяют одновременно проектировать БД и разрабатывать прикладные программы, использующие эти БД. Важно отметить, что даже "верхний уровень" имеет множество средств для описания обработки информации и хранения этих описаний в репозитории. Это подчеркивает тесную связь между проектированием БД и информационных систем, основанных на этих БД. Тем не менее, сохраняется принцип разделения БД и программ.

Интеграция функций часто приводит к сильной привязке CASE-системы к одной конкретной СУБД, для которой предназначены инструменты разработки прикладных программ. Это отражается в том, что репозиторий CASE поддерживается средствами "родной" СУБД, и генерация прикладных программ выполняется с использованием "родных" инструментов разработки этой же СУБД. Такие интегрированные CASE-системы часто ограничивают отображение концептуальной модели БД только на логическую схему, предопределенную для определенной СУБД.

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

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

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

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

Что касается классических методов проектирования, они остаются актуальными и в наше время. Системы баз данных, поддерживающие реляционную модель данных с расширениями с 1971 года, являются важным элементом. Использование иерархической "каскадной" схемы структурного проектирования БД, начиная с верхних уровней и двигаясь вниз, продолжает быть релевантным. CASE-системы для структурного проектирования БД и информационных систем, включая прикладные программы, также остаются важными инструментами. Они предоставляют различные модели данных и средства описания ограничений целостности, поддерживая тем самым разнообразие требований пользователей.

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

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

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

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

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

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

Информационные технологии, включая проектирование баз данных, стали не только стимулом для таких изменений, но и ключевым элементом обеспечения успеха и возможности планируемых реконструкций. Эти изменения привнесли новые требования к архитектуре корпоративных информационных систем и, как следствие, к проектированию корпоративных баз данных [3,4].

Этапы проектирования БД методом «восходящего» проектирования представлены на рисунке 1.

Рисунок 2. Этапы проектирования баз данных

ДЛМ – даталогическая модель; НФ – нормальная форма; ИЛМ – информационно—логическая модель предметной области; МБД – модель БД.

2. Этапы нормализации баз данных

К этапам нормализации баз данных можно отнести:

Анализ данных: Первоначальный этап означает сбор исходных данных на предприятии.

Составление реляционных схем: Информация переносится в реляционные отношения. Схема находится в 0НФ.

Приведение к 1НФ: Схема находится в 1НФ, если атрибуты имеют атомарные значения и отсутствуют повторяющиеся группы.

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

Выбор первичного ключа: Если есть несколько потенциальных ключей, выбирается кандидат в первичный ключ.

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

Приведение к 2НФ: Разделение схемы на составные части для устранения частичных функциональных зависимостей.

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

Анализ соответствия НФБК: Проверка соответствия нормальной форме Бойса – Кодда.

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

Таблица 1.

Сравнение методов проектирования БД

Заключение

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

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

Список литературы:

1. What is Database Design Methodology? Different Phases of Design Methodology. [Электронный ресурс] - Режим доступа:  https://ecomputernotes.com/database-system/rdbms/phases-of-design-methodology – (дата обращения  09.10.2023).
2. Анализ методов проектирования БД. [Электронный ресурс] - Режим доступа:   https://shpargalum.ru/shpora-gos-povtas/proektirovanie-avtomatizirovannyix-sistem-na-osnove-bd/analiz-metodov-proektirovaniya-bd.html – (дата обращения  09.10.2023).
3. Проектирование баз данных. [Электронный ресурс] - Режим доступа:   http://www.illari.ru/doc/it/articles/article_984.html – (дата обращения  09.10.2023).
4. Руководство по проектированию реляционных баз данных (1-3 часть из 15). [Электронный ресурс] - Режим доступа: https://habr.com/ru/articles/193136/ – (дата обращения  09.10.2023).
5. Старушенкова Е.Е. Основные этапы проектирования баз данных. [Электронный ресурс] - Режим доступа: https://cyberleninka.ru/article/n/osnovnye-etapy-proektirovaniya-baz-dannyh – (дата обращения  09.10.2023).