a little more edits
This commit is contained in:
+44
-8
@@ -10,12 +10,11 @@
|
||||
|
||||
Табличная форма удобна тем, что позволяет явно фиксировать элементы сети и их атрибуты, редактировать отдельные значения и проверять заполненность полей. При этом она допускает частично заданные конфигурации: часть параметров может быть указана сразу, а часть оставлена пустой для последующего уточнения.
|
||||
|
||||
При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: представление в первой нормальной форме и представление в третьей нормальной форме. Оба варианта позволяют формализовать описание сети, однако различаются удобством редактирования данных.
|
||||
|
||||
В первой нормальной форме данные представляются в виде одной или нескольких таблиц, где каждая строка содержит атомарные значения: имя узла, интерфейс, адреса, принадлежность сети и т.д.. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации.
|
||||
При разработке табличного представления конфигурации сети виртуальных машин рассматривались два варианта организации данных: представление в первой нормальной форме и представление в третьей нормальной форме. Оба варианта позволяют формализовать описание сети, однако различаются удобством редактирования данных. Вторая нормальная форма отдельно не рассматривалась как самостоятельный вариант представления, поскольку для данной задачи она является промежуточным этапом между компактным пользовательским описанием и полностью разнесённой структурой данных.
|
||||
|
||||
Разберём оба представления на примере топологии, изображённой на рисунке~\ref{fig:exmpl1}
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{files/exmpl1.png}
|
||||
@@ -23,7 +22,16 @@
|
||||
\label{fig:exmpl1}
|
||||
\end{figure}
|
||||
|
||||
Пример представления в 1НФ:
|
||||
\subsubsection*{Первая нормальная форма}
|
||||
|
||||
Первая нормальная форма (далее - 1НФ) \cite{DB}:
|
||||
|
||||
Переменная отношения находится в \textbf{1НФ} тогда и только тогда, когда в любом допустимом значении этой переменной отношения каждый её кортеж содержит только одно значение для каждого из атрибутов.
|
||||
|
||||
В первой нормальной форме данные представляются в виде одной таблицы, где каждая строка содержит атомарные значения: имя узла, интерфейс, адреса, принадлежность сети и т.д.. Такое представление остаётся достаточно простым для ручного заполнения и позволяет сразу видеть основную структуру конфигурации.
|
||||
|
||||
|
||||
Пример представления в 1НФ (таблица \ref{tab:1nf}):
|
||||
|
||||
\begin{table}[h!]
|
||||
\centering
|
||||
@@ -44,11 +52,29 @@ com\_right & Switch & eth3 & C & \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Network device configuration}
|
||||
\label{tab:1nf}
|
||||
\end{table}
|
||||
|
||||
\subsubsection*{Третья нормальная форма}
|
||||
|
||||
Третья нормальная форма (далее - 3НФ) \cite{DB}:
|
||||
|
||||
Переменная отношения находится в \textbf{3НФ} тогда и только тогда, когда её неключевые атрибуты, если они существуют, являются одновременно:
|
||||
|
||||
\begin{enumerate}
|
||||
\item взаимно независимыми;
|
||||
\item неприводимо зависимыми от первичного ключа.
|
||||
\end{enumerate}
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Неключевой атрибут} --- это атрибут, который не входит в состав первичного ключа рассматриваемой переменной отношения.
|
||||
|
||||
\item \textbf{Взаимно независимые атрибуты} --- это два или больше атрибутов, таких что ни один из них функционально не зависит от какой-либо комбинации остальных атрибутов. Подобная независимость подразумевает, что каждый такой атрибут может обновляться независимо от остальных атрибутов.
|
||||
\end{itemize}
|
||||
|
||||
В третьей нормальной форме данные разделяются на отдельные сущности: узлы, интерфейсы, сетевые сегменты и связи. Такой подход уменьшает дублирование данных и лучше соответствует классической реляционной модели, однако делает представление более громоздким. Для понимания одной связи приходится обращаться сразу к нескольким таблицам.
|
||||
|
||||
Пример представления в 3НФ:
|
||||
Пример представления в 3НФ (таблицы \ref{tab:3nf1} - \ref{tab:3nf3}):
|
||||
|
||||
\begin{table}[h]
|
||||
\centering
|
||||
@@ -65,6 +91,7 @@ com\_right & Switch & eth3 & C & \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Devices}
|
||||
\label{tab:3nf1}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[h]
|
||||
@@ -86,6 +113,7 @@ com\_right & eth3 & C \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Interfaces}
|
||||
\label{tab:3nf2}
|
||||
\end{table}
|
||||
|
||||
\begin{table}[h]
|
||||
@@ -101,21 +129,29 @@ PC4.eth1 & 10.0.0.4/24 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{IPs}
|
||||
\label{tab:3nf3}
|
||||
\end{table}
|
||||
|
||||
\subsubsection*{Выбор формы}
|
||||
|
||||
В качестве основного пользовательского представления была выбрана первая нормальная форма. Она удобнее для ручного заполнения, проще воспринимается при описании лабораторных стендов и не требует постоянного перехода между большим количеством связанных таблиц.
|
||||
|
||||
Табличное представление в 1НФ используется как удобная форма ввода, а при дальнейшей обработке данные могут преобразовываться во внутреннюю модель, где отдельно выделяются узлы, интерфейсы и связи. Такой подход сохраняет простоту заполнения таблицы и одновременно позволяет использовать данные для экспорта в YAML или построения диаграммы топологии.
|
||||
|
||||
\subsection{Внутренняя модель данных}
|
||||
|
||||
Табличное представление удобно для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор классов Python, соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого могут формироваться другие виды результата.
|
||||
Табличное представление удобно для ввода, но для дальнейшей обработки требуется программная структура, в которой связи между объектами выражены явно. Поэтому данные таблиц должны преобразовываться во внутреннее представление, например в набор классов Python (рисуок \ref{fig:uml_model1}), соответствующих основным сущностям конфигурации. Такая модель служит центральным представлением, из которого могут формироваться другие виды результата.
|
||||
|
||||
\todo[inline]{хоть и акцент обычно на табличках, это не совсем центральное. Представить пример uml для python классов}
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=0.8\textwidth]{files/UML.png}
|
||||
\caption{UML диаграмма классов Python}
|
||||
\label{fig:uml_model1}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Преобразование модели данных}
|
||||
|
||||
Также одной из подзадач является разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель, экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сеьи из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели.
|
||||
Также одной из подзадач является разработка механизмов преобразования модели. Основными преобразованиями являются импорт данных из табличного описания во внутреннюю модель , экспорт в формализованный файл конфигурации и построение диаграммы топологии. YAML-файл в этом случае используется как структурированное описание, пригодное для дальнейшей обработки программами, вроде Netloom для поднятия сети из виртуальных машин, а D2 может применяться для генерации визуального представления сети на основе уже построенной модели.
|
||||
|
||||
\subsection{Вывод}
|
||||
|
||||
|
||||
@@ -2,4 +2,3 @@
|
||||
\label{sec:Chapter5} \index{Chapter5}
|
||||
\todo[inline]{Здесь надо перечислить все результаты, полученные в ходе работы. Из текста должно быть понятно, в какой мере решена поставленная задача.}
|
||||
|
||||
вот реф \cite{GLPK} реф
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
direction: down
|
||||
|
||||
Interface: {
|
||||
shape: class
|
||||
|
||||
name: str
|
||||
itype: "[str]"
|
||||
adapter: "[str]"
|
||||
slave_interfaces: "[List[str]]"
|
||||
parent_interface: "[str]"
|
||||
ip_address: "[str]"
|
||||
network: "[str]"
|
||||
subnet_mask: "[str]"
|
||||
default_gateway: "[str]"
|
||||
vlan: "[str]"
|
||||
device: Device
|
||||
}
|
||||
|
||||
Device: {
|
||||
shape: class
|
||||
|
||||
name: str
|
||||
role: str
|
||||
interfaces: "Dict[str, Interface]"
|
||||
}
|
||||
|
||||
Host: {
|
||||
shape: class
|
||||
|
||||
role: str
|
||||
}
|
||||
|
||||
Router: {
|
||||
shape: class
|
||||
|
||||
role: str
|
||||
}
|
||||
|
||||
Switch: {
|
||||
shape: class
|
||||
|
||||
role: str
|
||||
}
|
||||
|
||||
Network: {
|
||||
shape: class
|
||||
|
||||
name: str
|
||||
interfaces: "List[Interface]"
|
||||
network_ip: "[str]"
|
||||
}
|
||||
|
||||
Topology: {
|
||||
shape: class
|
||||
|
||||
devices: "Dict[str, Device]"
|
||||
networks: "Dict[str, Network]"
|
||||
}
|
||||
|
||||
Host -> Device: {
|
||||
target-arrowhead.shape: triangle
|
||||
target-arrowhead.style.filled: false
|
||||
}
|
||||
|
||||
Router -> Device: {
|
||||
target-arrowhead.shape: triangle
|
||||
target-arrowhead.style.filled: false
|
||||
}
|
||||
|
||||
Switch -> Device: {
|
||||
target-arrowhead.shape: triangle
|
||||
target-arrowhead.style.filled: false
|
||||
}
|
||||
|
||||
Device -- Interface: interfaces {
|
||||
source-arrowhead: 1..*
|
||||
target-arrowhead: 1
|
||||
}
|
||||
|
||||
Network -- Interface: interfaces {
|
||||
source-arrowhead: 1..*
|
||||
target-arrowhead: 1
|
||||
}
|
||||
|
||||
Topology -- Device: devices {
|
||||
source-arrowhead: 1..*
|
||||
target-arrowhead: 1
|
||||
}
|
||||
|
||||
Topology -- Network: networks {
|
||||
source-arrowhead: 1..*
|
||||
target-arrowhead: 1
|
||||
}
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 210 KiB After Width: | Height: | Size: 125 KiB |
+86
-86
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 286 KiB After Width: | Height: | Size: 214 KiB |
Reference in New Issue
Block a user