12
Рисунок 1 – Пример связи «один-к-одному»
Говорят, что для таблиц установлена связь под названием «один-ко-
многим», в случае, когда каждая из записей таблицы А может связываться с
несколькими записями с В, а также каждая при этом запись в таблице В,
связываться с 1 записью с А не может.
В таком случае таблица А считается главной, а В – подчиненной.
Для связей применяется специальное поле, что будет являться
первичным ключом для рассматриваемой таблицы, которая и находится в
отношении с объектом А («один»), хотя и будет внешним ключом в той
таблице, что находится в категории «многие» (Б) (рисунок 2).[24]
Рисунок 2 – Пример связи «один-ко-многим»
Для таблиц с названиями А, В установлена связь типа «многие-ко-
многим», в случае, когда для каждой записи с таблицы А могут в соответствие
быть поставлены несколько записей из таблицы В.
Справедливо применять и обратное утверждение, когда для каждой
записи с таблицы В используется несколько записей для таблицы А.
13
Указанная выше связь всегда будет реализовываться при использовании
дополнительной третьей таблицы.
Рассмотренный тип связи – «многие-ко-многим» представляется всегда
комбинацией с 2-х одновременных связей вида «один-ко-многим»: например,
между двумя таблицами С, А (где С – подчиненная, А – главная), а также
между двумя таблицами С, В (где С – подчиненная, В – главная) (рисунок 3)
[35]:
Рисунок 3 – Реализация связи «многие-ко-многим»
Нужно также отметить, что при реализации процесса разработки БД
выделяют несколько самых главных этапов, которые будут также выполняться
вне зависимости указанной при выборе СУБД, а также технологии
проектирования базы данных.[28]
1. Выполнение описания основных элементов предметной области.
На указанном шаге формируется задание для непосредственно создания базы.
На нем описывается с большой подробностью состав БД, основные цели и
предназначение, перечисляется, какие именно виды работ по реализации
проектирования предполагается осуществить для создаваемой БД (изменение
данных, печать и прочие действия с БД).
2. Разработка схемы (или диаграммы) данных. На указанном этапе
рассматривается, как и из каких ИО есть возможность составить БД, а также
какими именно атрибутами описываются рассмотренные в предварительном
пункте ИО. [28]
14
Затем определяется структура в таблицах БД с указанием
непосредственных свойств атрибутов.
3. Синтез построенной модели и объектов, что предполагает
реализацию следующих операций в разработке баз:
– создание файла с проектируемой БД;
– создание структуры таблиц и описание полей;
– создание форм для ввода, редактирования или просмотра данных
[33];
– заполнение таблиц;
– работа с проектируемой базой: поиск данных, сортировка,
фильтрация информации;
– отбор данных непосредственно для таблиц в соответствии с
указанными критериями отбора, необходимостью их для реализации
рассмотренной предметной области;
– выполнение обработки информации (а именно, удаление,
добавление, выполнение промежуточных вычислений);
– отчетность по запросам.
Разработку непосредственно самой простой схемы данных выполняют в
следующей последовательности действий:
1) проектируется список общий полей, что отражают полностью все
атрибуты таблиц;
2) поля со списка будут распределяться по базовых таблицах с
имеющимися данными;
3) в соответствии с указанными свойствами данных определены
также свойства для полей;
4) для всех таблиц нужно выделять ключевое поле (минимум одно);
5) определить типы связей.
Отметим, что структуры для таблиц при указанных нами связях между
ними будут образовать диаграмму проектируемой БД.[30]
15
1.2. Типы баз данных
Все современные СУБД и базы данных можно классифицировать по
разным критериям.[25]
1. Классификация по МД.
Ядром практически всех БД является модель для представления данных
– это совокупность структурных методов для отображения данных, а также и
различных операций по их обработке.
С использованием моделей могут представляться ИО, а также их
взаимосвязи.
Классической иерархической МД называется структура с помощью
которой представляется совокупность всех элементов, которые располагаются
в порядке непосредственной их подчиненности и образуют структурное
дерево, показанное на рисунке 4. [26]
Рисунок 4 – Пример иерархической модели
К самым основным понятиям для классической иерархической модели
относятся такие:
– связи;
– уровни;
– узлы.
К примеру, узлом называется вся имеющаяся совокупность атрибутов
данных, что описывается ИО.
Иерархическая структура также удовлетворяет требованиям:
16
– каждый из узлов на более низком уровне будет относится только с
узлом, который размещен на высшем уровне;
– есть единственный узел (корень), который находится на самом
верхнем уровне и он не подчинен другому какому-то узлу;
– для каждого узла есть ровно 1 путь с верхнего узла (корня)
непосредственно к необходимому.
Примером описания организации рассмотренной структуры есть
схематическая модель автомобиля, что приведена на рисунке 5:[4]
Рисунок 5 – Пример применения иерархической структуры
Классическим представителем указанной древоподобной СУБД, что
базируется на принципах изменении иерархической схемы является
популярная в 80-е годы ХХ ст. СУБД IMS.
Сетевая МД основывается практически на аналогичных понятиях.
Которые применены в иерархической модели, но для нее каждый узел
связывается с любым иным узлом любого уровня.
Ниже, на рисунке 6, приведена схематически сетевая модель данных.
17
Рисунок 6 – Сетевая схема БД
Примером классической сетевой схемы организации данных может
служить совокупность данных, которая содержит в себе разные сведения по
студентах, что занимаются, к примеру, в разных спортивных секциях.
В указанном случае возможно также непосредственное участие одного с
студентов на нескольких разных секциях, участие пары из них в одной секции.
Графическое описание такой сетевой структуры, изображено ниже на рисунке
7.[13]
Рисунок 7 – Описание сетевой структуры на примере спортшколы
Реляционная модель часто использует организацию хранимой
информации на дисковых носителях в виде таблиц. Все ранее указанные в
модели таблицы, имеют название реляционных или же отношений, они
представляют собой матрицу данных, а также обладают такими свойствами:
18
– столбцы в таких таблицах являются однородными, а именно все их
элементы будут иметь только одинаковый тип и разные допустимые размеры
данных;
– идентичные записи отсутствуют;
– все имеющиеся поля имеют только одно уникальное имя;
– порядок для размещения в таблице разных столбцов и строк не
имеет для обработки ее никакого значения.[38]
Главными структурными компонентами в реляционной таблице
считаются запись, а также поле, которые показаны схематически на рисунке
8.[2]
Рисунок 8 – Структура для реляционной таблицы
Полем считается элементарная единица для реализации некоторой
логической организации данных, что соответствует конкретному атрибуту для
определенного ИО. [33]
Запись – совокупность связанных логически полей, которая
соответствует экземпляру ИО.
Например, в качестве двухмерных таблиц можно реализовать
представление разных данных о студентах, которые получают образование в
ВУЗе (рисунок 9).[20]
19
Рисунок 9 – Пример реляционного множества данных
2. Классификация БД по степени организации хранимых данных.
Все БД могут быть подразделены на:[28]
– неструктурированные – это такие базы, которые организованы
непосредственно в виде определенных сетей;
– частично структурированные – БД, которые имеют вид
традиционного текста, а также и гипертекстовые системы
хранения/отображения данных предметной области;
– структурированные – требуют реализации предварительного
проектирования, а также описания схемы БД. Только в результате выполнения
таких всех этапов БД могут быть заполнены данными. [38]
1.3. Источники угроз для БД, их классификация
Список самых главных уязвимостей для СУБД не претерпел какого-то
большого изменения за последние несколько лет. Выполнив анализ средств,
что выполняют обеспечение безопасности СУБД, а также просмотрев
архитектуру БД, разные инциденты с безопасностью, многие известные
уязвимости, выделим причины возникновения таких ситуаций:
– проблемами обеспечения безопасности для средств
разрабатываемых программ в основном занимаются только фирмы, что их и
производят;
– прикладные программисты, а также администраторы не всегда
особенное внимание уделяют вопросам безопасности;
20
– разные масштабы, виды хранимых данных часто требуют всегда
разнообразных подходов для реализации требуемого уровня безопасности БД;
– все самые разные СУБД используют для своей работы также
разные структуры ЯП при доступе к требуемой информации, что базируются
на такой же платформе;
– появляются новые типы и форматы моделей структуризации,
принципы для хранения данных.
Хранилища в объемных данных включают 2 такие компоненты, а
именно:
– хранимые данные (БД);
– программы для их упорядочивания, ввода и других операций
(СУБД).
Обеспечение уровня безопасности данных невозможно реализовать без
обеспечения управления ими.
Стоит отметить, что все уязвимости и вопросы по поддержке
безопасности СУБД разделяются на 2 основные категории, такие как:
– зависящие от применяемой в БД информации;
– прямо и непосредственно не зависящие от них.
Все уязвимости, которые по своей сущности не могут зависят от данных,
являются также типичными для всех других видов ПО.
Причиной угрозы может также являться несвоевременное или же
полностью некорректное обновление ПО, а также выявление многих
неиспользуемых в БД функций, недостаточная квалификация разработчиков и
администраторов, которые работают непосредственно с БД.
Большинство таких аспектов, что относятся также к безопасности СУБД
является зависящими в некотором роде от всей хранимой информации. В то
же время рассмотренные уязвимости являются также в некоторой степени и
зависимыми от данных, что используются.
Приведем пример, основной перечень СУБД поддерживает
использование запросов для данных с описанием их на языке для организации
21
запросов и манипуляции данными, который содержит самые разные наборы
доступных для пользователей встроенных функций или же любые функции
для ЯП высокого уровня.
Разные модели данных определяют все особенности языка, который
будет использоваться в БД, а также и наличие в нем самых разных типов
уязвимостей.
Причем такие рассмотренные уязвимости, к примеру, инъекции, можно
выполнять разными методами в зависимости от их синтаксиса.
Рассмотрим далее основные требования, которые выдвигаются для
безопасности БД.
При этом на основе такого разделения всех уязвимостей можно выделять
и другие независящие или же зависящие от хранимых данных меры для
обеспечения требуемого уровня безопасности.
Не зависящими называются такие требования к непосредственно
безопасной работе:[8]
1. Функционирование только в специальной доверенной зоне.
Под доверенной зоной часто понимают инфраструктуру некоторой
организации, другие ее защитные инструменты и механизмы, что обусловлены
разными политиками безопасности. В казанном случае речь идет также и о
работе СУБД, когда при некоторых правилах для безопасности используются
разные подсистемы организаций.
2. Организация физического уровня поддержки безопасности для
любых файлов и данных.
Требования физической безопасности файлов, что вовсе не отличаются
от самых основных условий, применимых к другим файлам или же
пользователям.
3. Организация безопасной, актуальной настройки для СУБД.
Рассмотренные основные требования включают главные задачи по
обеспечению безопасности:
– отключение неиспользуемых функций;