Проектирование информационных систем: комплексный подход к разработке курсовой работы на основе стандартов и методологий

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

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

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

Теоретические основы проектирования информационных систем

Понятие и классификация информационных систем

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

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

• Транзакционные информационные системы (ТИС), часто называемые OLTP-системами (On-Line Transaction Processing), являются фундаментом для большинства организаций. Их основное назначение — автоматизация и обработка повседневных, рутинных операций, таких как оформление продаж, управление запасами, регистрация финансовых транзакций или обработка заказов. ТИС обеспечивают высокую скорость выполнения операций, надежность и точность данных, что критически важно для поддержания непрерывности бизнес-процессов.
  

  Пример: банковские системы, системы бронирования билетов, кассовые аппараты.

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

  Пример: системы планирования ресурсов предприятия (ERP), системы управления взаимоотношениями с клиентами (CRM), системы бизнес-аналитики (BI).

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

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

• Географические информационные системы (ГИС) — это мощные инструменты для работы с пространственными данными. Они позволяют собирать, хранить, анализировать и визуализировать информацию, привязанную к географическим координатам. ГИС используются для создания интерактивных карт, моделирования географических процессов, планирования инфраструктуры, управления природными ресурсами и в урбанистике.
  

  Пример: навигационные системы, кадастровые системы, системы мониторинга окружающей среды.

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

  Пример: системы стратегического планирования, системы управления инвестиционным портфелем.

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

Требования к информационным системам

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

Требования к ИС можно классифицировать по нескольким уровням, отражающим их происхождение и детализацию:

1. Бизнес-требования: Это самый высокий уровень требований, формулируемый топ-менеджерами, акционерами или другими ключевыми стейкхолдерами предприятия. Они описывают высокоуровневые цели и задачи, которые бизнес стремится достичь с помощью новой системы. Например, «увеличить скорость обработки заказов на 20%» или «сократить операционные расходы на 15%». Эти требования носят стратегический характер и определяют общую направленность проекта.
2. Требования пользователей: Исходят непосредственно от конечных пользователей системы. Они описывают задачи, которые пользователи будут выполнять с помощью системы, и как они взаимодействуют с ней. Эти требования часто бывают неструктурированными, могут дублироваться или даже противоречить друг другу. Задача аналитика — собрать их, проанализировать, устранить конфликты и привести к единообразному виду. Пример: «пользователь должен иметь возможность быстро найти нужный товар», «система должна формировать отчет о продажах за любой период».
3. Функциональные требования: Предназначены для формализации и детализации того, что система должна делать. Они описывают конкретные функции и поведение системы в ответ на действия пользователя или внешние события. Функциональные требования непосредственно определяют логику работы системы. Пример: «система должна позволять регистрировать нового клиента», «система должна рассчитывать стоимость доставки на основе веса и расстояния».
4. Нефункциональные требования: Эти требования описывают, как система должна работать, то есть качество системы или продукта в целом. Они не связаны с конкретными функциями, но критически важны для удовлетворения пользователей и соответствия бизнес-целям. Нефункциональные требования охватывают широкий спектр аспектов, включая:
   • Надежность: Способность системы безотказно выполнять свои функции в течение определенного периода времени при заданных условиях.
   • Безопасность: Способность системы защищать данные и функциональность от несанкционированного доступа, использования, изменения или разрушения.
   • Масштабируемость: Способность системы эффективно работать при увеличении нагрузки (числа пользователей, объема данных, транзакций).
   • Производительность: Скорость отклика системы на действия пользователя, время выполнения операций, пропускная способность.
   • Удобство использования (юзабилити): Легкость освоения, эффективность использования и субъективное удовлетворение пользователя от работы с системой.
   • Сопровождаемость: Легкость внесения изменений, исправлений и улучшений в систему.
   • Совместимость: Способность системы взаимодействовать с другими системами или компонентами.

   Помимо этих качественных характеристик, нефункциональные требования также могут включать:

   • Ограничения: Условия, которые ограничивают выбор решений по реализации системы. Это могут быть технологические ограничения (например, использование определенной СУБД), бюджетные ограничения, временные рамки проекта, правовые или регуляторные требования.
   • Бизнес-правила: Политики, определяющие или ограничивающие аспекты бизнеса, которые должны быть реализованы в системе. Например, «скидка не может превышать 15%», «каждый заказ должен быть одобрен менеджером».

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

Жизненный цикл ИС и стандарты проектирования

Модели жизненного цикла информационных систем

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

В Российской Федерации значительную роль в стандартизации процесса создания автоматизированных систем играет ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания». Этот стандарт не только устанавливает стадии и этапы создания АС, но и служит основой для формирования унифицированного подхода к разработке, внедрению и сопровождению систем, обеспечивая тем самым прозрачность, управляемость и предсказуемость проекта.

Согласно ГОСТ 34.601-90, процесс создания автоматизированных систем включает восемь основных стадий, каждая из которых, в свою очередь, состоит из ряда детализированных этапов работ:

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

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

Стандарты и их роль в документировании проектирования ИС

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

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

1. ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Требования к содержанию документов». Этот стандарт является важным ориентиром для разработчиков, поскольку он распространяется на автоматизированные системы, используемые в самых разнообразных сферах деятельности, будь то исследования, управление или проектирование. Его основная задача – установить четкие и однозначные требования к содержанию основных документов, разрабатываемых на протяжении всего жизненного цикла АС.

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

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

Таким образом, ГОСТ Р 59795-2021 выступает в роли своего рода чек-листа, помогающего обеспечить полноту и корректность проектной документации, что критически важно для контроля качества и управления проектом.

2. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Если ГОСТ Р 59795-2021 регулирует общий объем документации, то ГОСТ 34.602-89 сосредоточен на одном из самых важных документов в любом IT-проекте – Техническом задании (ТЗ). ТЗ является краеугольным камнем, определяющим требования и порядок создания автоматизированной системы, а также служит основным документом для ее приемки при вводе в действие.

Стандарт определяет следующую структуру и содержание разделов ТЗ:

• Общие сведения: Общие данные о системе, ее наименование, заказчик, исполнитель, сроки выполнения.
• Назначение и цели создания системы: Подробное описание того, для чего создается система и какие бизнес-проблемы она должна решить.
• Характеристика объектов автоматизации: Описание предметной области, процессов, которые будут автоматизированы.
• Требования к системе: Центральный раздел, включающий функциональные, нефункциональные требования, требования к надежности, безопасности, эргономике и т.д.
• Состав и содержание работ по созданию системы: Описание стадий и этапов работ, распределение ответственности.
• Порядок контроля и приемки системы: Критерии и процедуры проверки качества системы.
• Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие: Что необходимо сделать для успешного внедрения системы.
• Требования к документированию: Перечень и состав документации, которая должна быть разработана.
• Источники разработки: Ссылки на нормативные документы, отчеты об исследованиях и другие исходные данные.

Соблюдение ГОСТ 34.602-89 при разработке ТЗ обеспечивает его полноту, однозначность и юридическую силу, что является залогом успешной реализации проекта и предотвращения возможных разногласий между заказчиком и исполнителем. Таким образом, стандарты не просто рекомендуют, они диктуют методологически корректный подход к проектированию ИС, обеспечивая ее качество и соответствие ожиданиям.

Методологии структурного проектирования и моделирование данных

Принципы структурного подхода к проектированию ИС

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

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

1. Принцип «разделяй и властвуй»: Это фундаментальный принцип, лежащий в основе всего структурного подхода. Его суть заключается в том, что решение любой сложной проблемы упрощается, если ее разбить на множество меньших, относительно независимых задач. Вместо того чтобы пытаться решить все сразу, разработчик фокусируется на отдельных частях, что позволяет более эффективно управлять сложностью и распределять работу. Например, проектирование большой корпоративной ИС может быть разделено на подсистемы управления финансами, персоналом, производством и т.д.
2. Принцип иерархического упорядочивания: Составные части проблемы, полученные в результате декомпозиции, организуются в иерархические древовидные структуры. На каждом последующем уровне иерархии добавляются новые детали, уточняющие предыдущий уровень. Это позволяет постепенно углубляться в детали, сохраняя при этом общую структуру и взаимосвязи. Например, функция «Обработка заказа» может быть разбита на подфункции «Прием заказа», «Проверка наличия», «Выставление счета» и т.д.
3. Принцип абстрагирования: На каждом уровне иерархии происходит выделение только существенных аспектов системы, игнорирование несущественных деталей. Это позволяет разработчикам сосредоточиться на ключевых характеристиках и поведении на данном уровне абстракции, не отвлекаясь на низкоуровневые подробности. Абстрагирование помогает управлять когнитивной нагрузкой и создавать более чистые, понятные модели.
4. Принцип формализации: Структурный подход требует использования строгого методического подхода и формальных языков для описания системы. Это могут быть графические нотации (например, диаграммы потоков данных, диаграммы сущность-связь), псевдокод или другие стандартизованные методы, которые обеспечивают однозначность и проверяемость проектных решений. Формализация минимизирует двусмысленность и позволяет автоматизировать некоторые этапы проектирования.
5. Принцип непротиворечивости: Все элементы системы, их свойства и взаимосвязи должны быть обоснованными и согласованными друг с другом. Отсутствие противоречий в проектных решениях гарантирует логическую целостность системы. Например, данные, используемые в одной функции, должны быть доступны и корректно интерпретированы в других функциях, которые с ними взаимодействуют.
6. Принцип структурирования данных: Данные, являющиеся сердцем любой информационной системы, должны быть структурированы и иерархически организованы. Это означает не просто хранение информации, а ее логическую организацию в таблицы, сущности, связи, что обеспечивает эффективность хранения, извлечения и обработки. Правильное структурирование данных является основой для построения надежной и производительной базы данных.

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

Моделирование данных с использованием нотации IDEF1X

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

IDEF1X – это стандарт, разработанный специально для описания данных (информации) и основанный на концепции «сущность-связь» (Entity-Relationship, ER). Она позволяет создавать модель данных, которая является эквивалентной реляционной модели данных (РМД) в 3^НФ (третьей нормальной форме), что критически важно для проектирования эффективных и непротиворечивых баз данных. Простота изучения и возможность автоматизации делают IDEF1X незаменимой в арсенале системного аналитика и проектировщика баз данных.

Ключевые элементы и принципы IDEF1X:

• Сущность: Представляет собой объект реального мира, информацию о котором необходимо хранить в базе данных. В IDEF1X сущности могут быть как независимыми, так и зависимыми.
  • Независимая сущность: Каждый экземпляр такой сущности однозначно идентифицируется без определения его отношений с другими сущностями. Это означает, что ее первичный ключ состоит только из ее собственных атрибутов. На диаграммах IDEF1X независимые сущности обычно изображаются прямоугольником с острыми углами.
  • Зависимая сущность: Идентификация экземпляра такой сущности требует определения ее отношения к другой сущности (родительской). Ее первичный ключ включает часть или весь первичный ключ родительской сущности. Зависимые сущности изображаются прямоугольником со скругленными углами.
• Атрибут: Характеристика сущности, которая описывает ее свойство. В IDEF1X к атрибутам предъявляются строгие правила:
  • Правило неповторяемости: Каждый атрибут сущности может принимать только одно значение. Это означает, что в одной ячейке таблицы не может быть списка значений или составных данных.
  • Правило не обращения в нуль: Любой экземпляр сущности должен содержать конкретное значение для каждого атрибута, входящего в первичный ключ. Это гарантирует уникальность и идентифицируемость каждой записи. Для других атрибутов может быть разрешено значение NULL, если оно не является частью первичного ключа и не нарушает бизнес-логику.
• Связи: Отношения между сущностями. В IDEF1X различают несколько типов связей, но наиболее важным является различие между идентифицирующими и неидентифицирующими связями:
  • Идентифицирующая связь: Устанавливается, когда первичный ключ дочерней сущности включает в себя часть или весь первичный ключ родительской сущности. Это делает дочернюю сущность зависимой от родительской.
  • Неидентифицирующая связь: Устанавливается, когда первичный ключ дочерней сущности не включает первичный ключ родительской. В этом случае первичный ключ родительской сущности переносится в дочернюю как внешний ключ, но не становится частью ее первичного ключа.

Пример применения IDEF1X:

Представим себе систему управления заказами.

Сущность КЛИЕНТ (независимая) с атрибутами: ID_Клиента (первичный ключ), Имя, Фамилия, Адрес.

Сущность ЗАКАЗ (зависимая) с атрибутами: ID_Заказа (первичный ключ, идентифицируется совместно с ID_Клиента), Дата_Заказа, Сумма_Заказа. Связь между КЛИЕНТ и ЗАКАЗ будет идентифицирующей, поскольку ID_Клиента является частью первичного ключа ЗАКАЗА.

IDEF1X-диаграммы широко используются в ряде распространенных CASE-средств, таких как ERwin Data Modeler и Design/IDEF. Эти инструменты позволяют не только визуально строить модели данных в нотации IDEF1X, но и автоматически генерировать SQL-скрипты для создания базы данных, а также проводить реверс-инжиниринг существующих баз данных. Это значительно ускоряет процесс проектирования, снижает количество ошибок и обеспечивает согласованность между логической моделью и физической реализацией.

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

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

Концептуальное, логическое и физическое проектирование баз данных

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

1. Концептуальное (инфологическое) проектирование.

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

   Ключевые характеристики:

   • Абстракция от реализации: Концептуальная модель данных полностью независима от таких деталей реализации, как тип выбранной СУБД (например, Oracle, PostgreSQL, MongoDB), набор прикладных программ, языки программирования или вычислительная платформа. Это позволяет сосредоточиться на бизнес-сущностях и их взаимосвязях, не отвлекаясь на технические ограничения.
   • Язык общения: Для создания концептуальной модели часто используются диаграммы «сущность-связь» (ERD), которые легко понимаются как бизнес-пользователями, так и техническими специалистами. Это способствует эффективной коммуникации и устранению недопонимания на ранних этапах.
   • Выявление сущностей и связей: На этом этапе выявляются ключевые объекты предметной области (сущности), их атрибуты и взаимосвязи между ними. Например, в системе учета студентов сущностями могут быть «Студент», «Преподаватель», «Курс», а связями – «Студент записывается на Курс», «Преподаватель ведет Курс».
2. Логическое (даталогическое) проектирование.

   Цель этого этапа – преобразовать концептуальную модель данных в логическую, которая учитывает особенности выбранной модели организации данных в целевой СУБД. Если концептуальное проектирование было про «что», то логическое начинает затрагивать «как», но все еще на достаточно высоком уровне.

   Ключевые характеристики:

   • Зависимость от модели СУБД: Если концептуальная модель была универсальной, то логическая модель уже ориентирована на конкретный тип СУБД (например, реляционная, иерархическая, сетевая). Для реляционных баз данных это означает преобразование ER-диаграммы в набор таблиц, столбцов, первичных и внешних ключей.
   • Нормализация: На этом этапе активно применяются правила нормализации (до 3^НФ или выше) для устранения избыточности данных, предотвращения аномалий при вставке, удалении и обновлении, а также улучшения структуры таблиц.
   • Ограничения целостности: Определяются логические ограничения целостности, такие как уникальность, NOT NULL, первичные и внешние ключи, которые будут поддерживаться СУБД.
3. Физическое проектирование.

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

   Ключевые характеристики:

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

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

Ограничения целостности базы данных

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

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

1. По области действия:
   • Ограничения домена: Самый базовый уровень. Устанавливают допустимые значения для определенных типов данных в столбце. Например, числовой столбец может быть ограничен диапазоном положительных значений, а текстовый – списком предопределенных категорий.
   • Ограничения атрибута: Относятся к одному конкретному атрибуту (столбцу) и его свойствам. Примеры: NOT NULL (запрещает пустые значения), UNIQUE (требует уникальности значений в столбце или группе столбцов).
   • Ограничения кортежа (строки): Накладываются на всю строку таблицы и могут учитывать взаимосвязи между значениями разных атрибутов в пределах одной записи. Например, «дата окончания не может быть раньше даты начала».
   • Ограничения отношения (таблицы): Известные также как целостность сущностей, они гарантируют, что каждая запись в таблице имеет уникальный идентификатор. Главным примером является ограничение PRIMARY KEY (первичный ключ), которое обеспечивает уникальную идентификацию каждой записи и запрещает пустые значения для его компонентов.
   • Ограничения базы данных: Известные как целостность по ссылкам (или ссылочная целостность), они охватывают отношения между несколькими таблицами. FOREIGN KEY constraint (внешний ключ) является ярким примером, гарантируя, что значения внешних ключей в одной таблице ссылаются только на существующие значения первичных ключей в другой (родительской) таблице. Это предотвращает «висячие» ссылки и обеспечивает связность данных.
2. По способам реализации:
   • Декларативная поддержка: Это наиболее предпочтительный способ, когда ограничения определяются непосредственно средствами языка DDL (Data Definition Language) при создании или изменении структуры таблицы. Например, с помощью операторов CREATE TABLE или ALTER TABLE мы можем объявить PRIMARY KEY, FOREIGN KEY, NOT NULL, UNIQUE, CHECK.
   • Процедурная поддержка: Используется для реализации более сложной логики ограничений, которую невозможно выразить декларативно. Это достигается с помощью триггеров и хранимых процедур. Триггеры – это специальные процедуры, которые автоматически выполняются при определенных событиях (вставка, обновление, удаление) в таблице и могут содержать сложную логику проверки данных.
3. По времени проверки:
   • Немедленно проверяемые ограничения (Immediate): Про��еряются непосредственно в момент выполнения операции, способной нарушить ограничение. Например, при попытке вставить запись с дублирующимся первичным ключом, система немедленно выдаст ошибку.
   • Ограничения с отложенной проверкой (Deferred): Проверяются не сразу после выполнения операции, а в момент фиксации всей транзакции оператором COMMIT WORK. Это позволяет выполнять несколько операций, которые временно нарушают ограничения, но к моменту фиксации транзакции все ограничения должны быть соблюдены. Это полезно в сценариях, где для выполнения операции требуется временное нарушение целостности, которое затем устраняется другими операциями в той же транзакции.

Пример:

Создание таблицы Студенты с первичным ключом ID_Студента и ограничением NOT NULL для Имя:

CREATE TABLE Студенты (
    ID_Студента INT PRIMARY KEY,
    Имя VARCHAR(50) NOT NULL,
    Фамилия VARCHAR(50),
    Дата_Рождения DATE
);

Создание таблицы Курсы и ЗаписьНаКурс с ограничением внешнего ключа:

CREATE TABLE Курсы (
    ID_Курса INT PRIMARY KEY,
    Название_Курса VARCHAR(100) UNIQUE
);

CREATE TABLE ЗаписьНаКурс (
    ID_Записи INT PRIMARY KEY,
    ID_Студента INT,
    ID_Курса INT,
    Дата_Записи DATE,
    FOREIGN KEY (ID_Студента) REFERENCES Студенты(ID_Студента),
    FOREIGN KEY (ID_Курса) REFERENCES Курсы(ID_Курса)
);

В данном примере ID_Студента и ID_Курса в таблице ЗаписьНаКурс являются внешними ключами, обеспечивающими ссылочную целостность: невозможно записать студента или курс, которых не существует в соответствующих родительских таблицах.

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

Проектирование пользовательского интерфейса и взаимодействие с внешними данными

Общие подходы к проектированию пользовательского интерфейса

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

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

1. Ориентация на пользователя (User-Centered Design): Это основополагающий принцип, требующий ставить пользователя в центр процесса проектирования. Все решения должны приниматься исходя из потребностей, задач, опыта и ограничений целевой аудитории. Это включает в себя глубокий анализ пользователей, их сценариев работы (User Stories, Use Cases), создание персон и постоянное тестирование с реальными пользователями.
2. Интуитивность и простота: Интерфейс должен быть максимально простым и понятным, не требующим от пользователя специальных знаний или длительного обучения. Элементы управления должны быть узнаваемыми и предсказуемыми, а навигация – логичной. Принцип «не заставляй меня думать» (Don’t Make Me Think) является здесь ключевым.
3. Последовательность и единообразие: Элементы интерфейса, терминология, расположение кнопок, цветовые схемы и шрифты должны быть единообразны во всей системе. Это создает ощущение предсказуемости и помогает пользователю быстрее освоить систему, поскольку знания, полученные в одном разделе, применимы в других.
4. Обратная связь: Система должна постоянно информировать пользователя о своих действиях и состоянии. Это может быть индикатор загрузки, сообщение об успешном сохранении данных, подсветка выбранного элемента или предупреждение об ошибке. Отсутствие обратной связи создает ощущение «зависания» и неопределенности.
5. Гибкость и эффективность: Интерфейс должен предлагать как простые пути для новичков, так и более быстрые и эффективные способы выполнения задач для опытных пользователей (например, горячие клавиши, настраиваемые меню). Это обеспечивает масштабируемость взаимодействия по мере роста компетенции пользователя.
6. Устойчивость к ошибкам (Error Prevention and Recovery): Хороший UI предотвращает ошибки, например, через валидацию ввода или подтверждение деструктивных действий. Если же ошибка произошла, система должна предоставлять четкие и полезные сообщения об ошибках, а также возможности для их легкого исправления (например, кнопка «Отмена», история действий).
7. Эстетика и привлекательность: Визуальная привлекательность интерфейса не является второстепенной. Аккуратный дизайн, сбалансированная цветовая палитра, читабельные шрифты и отсутствие визуального шума способствуют приятному пользовательскому опыту и повышают доверие к системе.

Процесс проектирования UI обычно включает:

• Исследование: Изучение пользователей, их потребностей, контекста использования.
• Анализ: Определение функциональных и нефункциональных требований к интерфейсу.
• Создание прототипов (Wireframes, Mockups): Разработка черновых макетов, позволяющих быстро протестировать идеи без написания кода.
• Тестирование юзабилити: Проверка интерфейса с реальными пользователями для выявления проблем и узких мест.
• Итеративная доработка: Постоянное улучшение UI на основе полученной обратной связи.

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

Сравнительный анализ ODBC и OLE DB

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

Характеристика	ODBC (Open Database Connectivity)	OLE DB (Object Linking and Embedding, Database)
Основное назначение	Стандартный API (Application Programming Interface), предоставляющий универсальный интерфейс для доступа к системам баз данных, используя SQL для взаимодействия.	Набор COM-основанных API, разработанных Microsoft для обеспечения унифицированного доступа к разнообразным форматам данных в различных хранилищах.
Тип источников данных	В основном предназначен для доступа к реляционным базам данных, так как ориентирован на SQL.	Поддерживает более широкий спектр источников данных, включая нереляционные и неструктурированные форматы (например, электронные письма, текстовые файлы, графические данные, объекты файловой системы).
Ориентация на язык	Жестко ориентирован на SQL. Вся коммуникация с БД осуществляется через SQL-запросы.	Обеспечивает более богатый и гибкий интерфейс для доступа к данным, поскольку не привязан жестко к синтаксису команд (как SQL в случае ODBC). Может работать с данными, которые не имеют SQL-интерфейса.
Гибкость и возможности	Преимущественно фокусируется на базовых операциях извлечения и обработки данных.	Предлагает расширенные возможности, включая более сложные команды для детальных манипуляций с данными, доступ к информации о схеме (метаданным) и управление распределенными транзакциями.
Кросс-платформенность	Поддерживает кросс-платформенную работу, совместим с Windows, Linux, Mac и UNIX.	В основном предназначен для платформы Windows и зависит от модели объектных компонентов (COM), которая недоступна в других операционных системах.
Архитектура	Использует архитектуру драйверов: приложение → Диспетчер драйверов ODBC → Драйвер БД → Источник данных.	Основан на провайдерах данных: приложение → Провайдер OLE DB → Источник данных. Провайдеры могут быть как для реляционных, так и для нереляционных источников.
Место на рынке	Является более устоявшимся интерфейсом, дольше присутствует на рынке, имеет проверенные драйверы и приложения.	Был разработан позже, является частью стратегии Microsoft по унифицированному доступу к данным.
Взаимодействие	OLE DB включает функциональность ODBC. Это означает, что OLE DB провайдер может использовать ODBC драйвер для доступа к реляционным БД.

Выводы:

• ODBC – это ветеран в сфере доступа к данным, его универсальность и кросс-платформенность делают его отличным выбором для работы с традиционными реляционными базами данных в гетерогенных средах. Если ваша система в основном работает с SQL и должна быть переносимой, ODBC – предпочтительный вариант.
• OLE DB – это более современный и мощный подход, особенно если требуется доступ к разнообразным источникам данных, выходящим за рамки реляционных баз. Его архитектура предоставляет большую гибкость и контроль над данными, а также расширенную функциональность. Однако его привязка к платформе Windows и технологии COM ограничивает его кросс-платформенное применение.

При проектировании ИС, выбор между ODBC и OLE DB должен основываться на конкретных требованиях к типу источников данных, функциональности, необходимой для работы с этими данными, а также на целевой операционной системе. В условиях, когда требуется доступ к данным как реляционного, так и нереляционного типа, OLE DB может предложить более унифицированное решение, но в кросс-платформенных проектах ODBC сохраняет свою актуальность.

Описание предметной области и сбор требований

Методы описания предметной области

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

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

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

Ключевые методы описания предметной области включают:

1. Исследование документации: Анализ существующих документов организации (отчеты, инструкции, положения, бизнес-процессы) помогает понять, как функционирует предметная область сейчас, какие данные обрабатываются и какие правила действуют.
2. Интервьюирование и опросы: Прямое общение с экспертами предметной области, конечными пользователями, менеджерами позволяет выявить их потребности, ожидания, проблемы и неформализованные знания.
3. Наблюдение: Изучение рабочих процессов «на месте» помогает увидеть, как пользователи взаимодействуют с существующими системами, какие возникают сложности, какие операции выполняются.
4. Построение глоссария: Создание единого словаря терминов предметной области с их однозначными определениями. Это критически важно для устранения двусмысленности и обеспечения общего понимания среди всех участников проекта.
5. Моделирование потоков данных: Использование диаграмм потоков данных (DFD) для визуализации того, как информация перемещается между процессами, сущностями и хранилищами данных в предметной области.
6. Моделирование сущность-связь (ERD): Построение концептуальной модели данных, которая графически отображает основные сущности предметной области, их атрибуты и взаимосвязи. Это позволяет структурировать информацию и выявить ключевые объекты, которые будут храниться в базе данных.
7. UML-диаграммы: В объектно-ориентированном подходе, диаграммы классов, вариантов использования, активности и последовательности могут быть использованы для моделирования статических и динамических аспектов предметной области.

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

Сбор и систематизация требований пользователя

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

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

Этапы и методы сбора и систематизации требований:

1. Сбор требований (Elicitation):
   • Интервью: Один из наиболее распространенных и эффективных методов. Проводятся структурированные беседы с ключевыми стейкхолдерами (заказчиками, конечными пользователями, экспертами предметной области) для выявления их потребностей и ожиданий.
   • Брейнсторминг: Групповые сессии, направленные на генерацию идей и выявление требований. Позволяет быстро собрать большой объем информации.
   • Наблюдение: Аналитик наблюдает за тем, как пользователи выполняют свои задачи в реальной рабочей среде, что помогает выявить неявные требования и проблемы, о которых сами пользователи могут не упоминать.
   • Анализ документов: Изучение существующих отчетов, форм, инструкций, нормативных актов и других материалов, которые могут содержать информацию о текущих бизнес-процессах и требованиях.
   • Рабочие сессии (Workshops/Joint Application Development — JAD): Сессии с участием представителей всех заинтересованных сторон, направленные на совместное обсуждение и определение требований. Эффективны для достижения консенсуса.
   • Прототипирование: Создание интерактивных макетов или упрощенных версий системы для получения обратной связи от пользователей на ранних этапах.
2. Систематизация и анализ требований:
   • Классификация: Разделение требований на функциональные, нефункциональные, бизнес-требования, пользовательские требования, ограничения и бизнес-правила.
   • Приоритизация: Определение важности и срочности каждого требования. Помогает в управлении проектом и планировании итераций.
   • Выявление взаимосвязей и конфликтов: Определение зависимостей между требованиями и разрешение противоречий. Использование матриц трассируемости помогает отслеживать, как требования связаны с компонентами системы и тестовыми сценариями.
   • Декомпозиция: Разбиение сложных требований на более мелкие, управляемые части.
   • Моделирование: Использование различных диаграмм (например, Use Case Diagram, Activity Diagram из UML, Data Flow Diagram) для визуального представления требований и процессов.
3. Документирование требований:
   • Результаты анализа требований должны быть зафиксированы в виде формальных документов. В российской практике стандартизации большое значение имеют ГОСТы:
     • ГОСТ Р 59795-2021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Требования к содержанию документов» устанавливает требования к содержанию различных документов, включая те, что описывают общие системные решения и процессы деятельности объекта автоматизации. Он помогает структурировать описание функциональности и нефункциональных характеристик будущей системы.
     • ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» является ключевым документом. Он детально определяет состав, содержание и правила оформления Технического задания (ТЗ), которое является основным документом, определяющим требования и порядок создания автоматизированной системы, а также используется для ее приемки при вводе в действие. Разделы ТЗ, такие как «Требования к системе», «Назначение и цели создания системы», непосредственно описывают результаты сбора и систематизации требований.
4. Проверка, утверждение и тестирование требований:
   • Проверка: Убеждение в том, что требования полны, однозначны, согласованы, проверяемы и реалистичны.
   • Утверждение: Получение формального согласия всех стейкхолдеров на набор требований.
   • Тестирование: Разработка тестовых сценариев на основе требований еще до начала кодирования. Это помогает убедиться, что система будет соответствовать заявленным функциям.

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

Заключение

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

Далее был проанализирован жизненный цикл информационных систем, где ключевую роль играют государственные стандарты. Были детально рассмотрены стадии создания автоматизированных систем согласно ГОСТ 34.601-90, а также требования к документированию по ГОСТ Р 59795-2021 и правила оформления технического задания по ГОСТ 34.602-89. Эти стандарты не просто регламентируют процесс, но и служат основой для обеспечения качества, управляемости и юридической чистоты проектной документации.

В части методологий структурного проектирования мы углубились в ключевые принципы, такие как «разделяй и властвуй», иерархическое упорядочивание, абстрагирование, формализация, непротиворечивость и структурирование данных. Особое внимание было уделено нотации IDEF1X как мощному инструменту семантического моделирования данных, ее связи с реляционной моделью (3^НФ) и применению в CASE-средствах, таких как ERwin. Были объяснены понятия независимой сущности, а также правила неповторяемости и не обращения в нуль для атрибутов, что является фундаментом для построения нормализованных баз данных.

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

Наконец, было исследовано проектирование пользовательского интерфейса с акцентом на интуитивность, последовательность и обратную связь. Проведен сравнительный анализ технологий ODBC и OLE DB, выявивший их различия в доступе к данным, гибкости и кросс-платформенности, что является важным аспектом при интеграции ИС с внешними источниками. Завершающий блок был посвящен методам описания предметной области и систематизации требований пользователя, что является отправной точкой для любого успешного проекта.

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

Список использованной литературы

1. Маслеников, К. Ю. Описание предметной области как неотъемлемый элемент процесса проектирования автоматизированной информационной системы / К. Ю. Маслеников, Г. И. Ревунков, М. В. Сатова. – 2017. – URL: https://naukovedenie.ru/PDF/55TVN617.pdf.
2. Структурный подход к проектированию ИС // CITForum.ru. – URL: https://citforum.ru/consulting/is/strupr/.
3. Выбор методологии моделирования предметной области при проектировании информационной системы // Эдиторум — naukaru.ru. – URL: https://naukaru.ru/ru/nauka/article/19530/view.
4. Подход к моделированию предметной области в информационных системах // Elibrary. – 2022. – URL: https://elibrary.ru/item.asp?id=48602787.
5. Лекция 1. Общие требования к проектированию ИС и технологий // MSUniversity. – URL: http://www.msu-edu.ru/course/view.php?id=30&section=1.
6. Обоснование и разработка требований к программным системам // ЭБС Лань. – URL: https://e.lanbook.com/book/75204.
7. ГОСТ Р 59795-2021. Информационные технологии. Комплекс стандартов на автоматизированные системы. Требования к содержанию документов. – URL: https://docs.cntd.ru/document/1200181512.
8. Документация для информационных систем по ГОСТ // DocPlace.ru. – 2017. – URL: https://docplace.ru/articles/dokumentatsiya-dlya-informatsionnyh-sistem-po-gost.
9. Виды информационных систем: ключевые аспекты и применение // Институт Информационных Систем ГУУ. – 2023. – URL: https://iis.guu.ru/news/vidy-informatsionnyh-sistem-klyuchevye-aspekty-i-primenenie/.
10. Comparing OLE DB and ODBC // SAS. – URL: https://www.sas.com/content/dam/SAS/support/en/doc-library/v94/Comparing_OLEDB_ODBC.pdf.
11. Теоретические основы информационных систем // ELiS ПГНИУ. – URL: https://elis.psu.ru/node/10202.
12. Физическое проектирование базы данных // Студенческий научный форум. – 2012. – URL: https://scienceforum.ru/2012/article/2012003882.