Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

экзамен

.pdf
Скачиваний:
0
Добавлен:
19.01.2026
Размер:
3.28 Mб
Скачать

1. Требования к данным. Основные виды и описание. Определение базы данных.

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

База данных - совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных (ГОСТ Р ИСО МЭК ТО 10032-2007).

К СУБД выдвигают ряд основных требований:

•Непротиворечивость данных, Актуальность хранимых данных, Надежность,

•Возможность модификации системы, Скорость доступа, Обеспечение безопасности данных.

Существует классификация СУБД

•Файл-серверные (Данные хранятся централизовано, СУБД – локально, согласованность посредством блокировок. Ms Access, Fox pro, Visual Fox pro)

•Клиент-серверные (Данные хранятся централизовано, СУБД – централизовано,

согласованность средствами СУБД. MySQL, Ms SQL server, Oracle, Firebird)

•Встраиваемые (Данные хранятся локально, СУБД – локально, согласованность не является проблемой. SQLite, MS SQL Server Compact)

2.Архитектуры СУБД. Уровни архитектуры БД. Модели баз данных (коротко, определения и примеры).

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

Уровни архитектуры БД – внешний уровень (представление), концептуальный уровень (обработка), внутренний уровень (хранение).

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

На сегодняшний день выделяют следующие модели данных:

•1) Сетевая

•2) Иерархическая

•3) Реляционная

•4) Объектно-ориентированная

•5) Объектно-ориентированная реляционная

•6) XML-ориентированная

•7) документ-ориентированная

•8) постреляционная

3. Реляционная модель баз данных (подробно). Определения.

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

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

•Опр. Атрибут – элементарная информационная единица, входящая в состав отношения на физическом уровне – поле.

•Опр. Кортеж – совокупность атрибутов, образующая запись.

•Опр. Домен – набор уникальных значений, которые может принимать атрибут.

•Опр. Степень отношения – число входящих в отношение атрибутов.

•Опр. Мощность отношения – количество записей, входящих в отношение.

4. Проектирование ИС. Этапы проектирования ИС. Построение концептуальной схемы.

Проектирование ИС:

проектирование объектов данных, которые будут реализованы в базе данных;

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

учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

Основные этапы проектирования

Анализ требований

Концептуальный дизайн (ER)

Логический дизайн (реляционная схема)

Нормализация схемы (xНФ)

Физический дизайн (нагрузка, индексы)

Приложения и безопасность (grants)

Концептуальное проектирование

• Цель данной стадии – сбор и структурирование информации о предметной области, которая должна быть отражена в БД. Обычно данная стадия оканчивается построением модели независимой схемы данных. В процессе работы делается акцент на определения порядка и способа получения, преобразования, вывода информации с правилами и ограничениями, накладываемыми как на данные, так и на операции над ними. Если проводить аналогию с проектированием АС, то эта стадия реализуется в предпроектном обследовании объекта автоматизации.

Концептуальная схема

• Проектирование информационных систем

Классификация и основы

Жизненный цикл ПО

Организация разработки

Анализ и моделирование области внедрения

Способы моделирования ИС

Нормализация БД

ERD

IDEF

DFD

SADT

UML

5. Жизненный цикл ИС. Модели жизненного цикла.

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

Модели жизненного цикла

• Каскадная модель

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

• Поэтапная модель

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

• Спиральная модель

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

6.Моделирование предметной области. Требования к моделям предметных областей. Аспекты функционирования моделей.

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

Требования к моделям предметных областей

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

понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;

реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;

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

7. IDEF0. История. Элементы. Определения. Требования.

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

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

Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий.

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

интерфейсная дуга, декомпозиция, глоссарий.

Требования стандарта IDEF0

В левом верхнем углу всегда – главный элемент.

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

Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.

Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.

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

8. Контекстная диаграмма. Основные потоки. Декомпозиция. Примеры.

Контекстная диаграмма (Context Diagram). Это высокоуровневая диаграмма потоков данных, которая отображает взаимодействие разрабатываемой системы с другими внешними сущностями, с которыми она связана.

Порядок построения контекстуальной диаграммы

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

2) Для бизнес-процесса определяются управляющие потоки. Сюда относятся: документы, ГОСТы, регламенты, приказы, распоряжения, чертежи, инструкции, которые описывают правила выполнения бизнес-процесса, самим бизнеспроцессом не меняются.

3) Для бизнес-процесса определяются выходные потоки. К ним относятся: отчеты, документы, изделие, чертеж, информация, которые являются результатом выполнения БП. У каждого БП минимум 1 выход.

4) Определение механизмов. Механизм – инструмент, оборудование, персонал, с помощью которых выполняется указанный БП.

Порядок построения диаграммы декомпозиции

1) На диаграмме декомпозиции рекомендуют расположить от 3-х до 8 работ в рамках БП. Если БП сложный, то сначала выделяют укрупненные блоки работ, из которых строят декомпозицию 1-го уровня. Далее для укрупненного блока строят свою диаграмму декомпозиции 2-го уровня и т.д. пока весь БП не будет разбит на простые, однозначные работы.

Работы на чертеже располагаются по диагонали от левого верхнего угла в правый нижний.

• 2) Далее по аналогии с контекстной диаграммой для каждой работы определяется входы, выходы, управление, механизм. Если потоки используются в нескольких работах, то они оформляются в виде ветвления с подписью у точки ветвления.

В декомпозиции появляются документированные разновидности потоков:

1)прямой выход вход;

2)Прямой выход управление;

3)Прямой выход механизм;

4)Обратный выход вход;

5)Обратный выход управление.

9. Моделирование данных. ERD. Определения.

ER диаграмма – предназначены для разработки и представления модели данных, являются исходными для построения схемы БД в выбранной СУБД.

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

Опр. Набор сущностей – объекты с одинаковой структурой характеристик (свойств или атрибутов), с помощью которых они могут быть описаны.

Опр. Связь – ассоциация, устанавливаемая между 2 или более сущностями.

Опр. Набор связей – ассоциация, установленная между двумя или более наборами сущностей

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

10. Связи в ERD. Виды связей.

Опр. Связь – ассоциация, устанавливаемая между 2 или более сущностями.

Опр. Тип связи. Существует 4 типа связи:

1.Один к одному

2.Один ко многим

3.Многие к одному

4.Многие ко многим

Опр. Для связей вводится понятие кардинальность связи – это свойство, которое говорит, что данная связь должна обязательно присутствовать.

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

11. Этапы построения ERD. Моделирование. Объединение. Слияние. Агрегация.

Этапы построения ER диаграмм:

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

2)Анализируем каждый набор объектов и определяем набор атрибутов этих объектов.

3)Установление ассоциаций между наборами атрибутов сущностей. Данный шаг можно выполнить несколькими путями:

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

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

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

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

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

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

адекватно отражать представление пользователя о данных;

давать возможность ответа на возможные запросы пользователя, причем делать это с минимальными затратами по количеству просматриваемых сущностей;

представлять данные с минимальным дублированием.

Объединение данных — это процесс объединения двух или более наборов данных в единую базу данных.

Объединение локальных моделей

слияние идентичных элементов;

установление связей между наборами сущностей разных моделей;

введение новых агрегированных элементов для представления связей между элементами разных моделей;

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

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

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

Обобщение данных — это процесс сокращения, упрощения и концентрации больших объемов информации, чтобы выделить ее основные характеристики и тенденции.

12. Ограничения целостности. Естественные ключи. Суррогатные ключи. Другие ключи.

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

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

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

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

Candidate key (потенциальный ключ) - представляет собой минимальный суперключ отношения (таблицы), то есть набор атрибутов, который удовлетворяет ряду условий:

-Неприводимость: он не может быть сокращен, он содержит минимально возможный набор атрибутов

-Уникальность: он должен иметь уникальные значения вне зависимости от изменения строки

-Наличие значения: он не должен иметь значения NULL, то есть он обязательно должен иметь значение.

Первичный ключ (primary key) непосредственно применяется для идентификации строк в таблице. Он должен соответствовать следующим ограничениям:

Первичный ключ должен быть уникальным все время

Он должен постоянно присутствовать в таблице и иметь значение

Он не должен часто менять свое значение. В идеале он вообще не должен изменять значение.

Альтернативными ключами (alternate key) называют потенциальный ключ, не выбранный первичным ключом.

Интеллектуальный («разумный») ключ, или ключ со смысловым значением (информативный) (intelligent key). Ключ со смысловым значением является, конечно, уникальным, и его значение имеет смысл для пользователя, например, личный код.

Внешний ключ (foreign key) указывает другому отношению, помогает в обеспечении ссылочной целостности (пример и объяснение в предыдущей главе). Позволяет связать отношения / записи друг с другом.

13. Порождение реляционных отношений из ERD. Нормализация. Термины.

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

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

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

Атрибут — свойство некоторой сущности. Часто называется полем таблицы.

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

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

Отношение — конечное множество кортежей (таблица).

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

Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.

Общая методика нормализации

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

2) Для каждого класса объектов выполняется поиск удачных естественных ключей , выполняется проверка на их уникальность, в случае, если естественных ключей не обнаружено, вводятся искусственные ключи.

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

14. Нормализация. Термины. 1НФ, 2НФ, 3НФ, НФБК. Примеры не из википедии.

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

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

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

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

Атрибут — свойство некоторой сущности. Часто называется полем таблицы.

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

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

Отношение — конечное множество кортежей (таблица).

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

Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.

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

Атомарность. Правило: поля не имеют дубликатов в каждой записи и каждое поле содержит только одно значение.

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

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