Данные в сетевой модели данных представляются в виде чего
Проектирование баз данных и работа с ними Веб-приложений. Введение в БД, SQL Server, ADO.NET
9.1.2.1.2. Сетевые
Если структура данных оказывалась сложнее, чем обычная иерархия, простота структуры иерархической базы данных становилась ее недостатком [16].
Основные принципы сетевой модели данных были разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных ( COnference on DAta SYstem Languages) CODASYL в 1971 г. [12].
Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа.
Основным недостатком сетевых баз данных (как и иерархических) является то, что они очень «жесткие» [16]. Изменение структуры базы данных обычно означало перестройку всей базы данных.
9.1.2.1.3. Реляционные
Для лучшего понимания РМД следует отметить три важных обстоятельства:
К сожалению, практическое определение понятия «реляционная база данных» оказалось гораздо более расплывчатым, чем точное математическое определение, данное этому термину Коддом в 1970 году. В первых реляционных СУБД не были реализованы некоторые из ключевых частей модели Кодда, и этот пробел был восполнен только впоследствии. По мере роста популярности реляционной концепции реляционными стали называться многие базы данных, которые на деле таковыми не являлись.
В ответ на неправильное использование термина «реляционный» Кодд в 1985 году написал статью, где сформулировал 12 правил, которым должна удовлетворять любая база данных, претендующая на звание реляционной [15]:
Приведенное определение не оставляет места встроенным указателям, имеющимся в иерархических и сетевых СУБД.
9.1.2.1.4. Постреляционные
Существует несколько коммерческих постреляционных СУБД, самыми известными из которых являются системы Adabas, Pick и Universe.
9.1.2.1.5. Объектно-ориентированные
В основу объектной модели положена концепция объектно-ориентированного программирования, в которой данные представляются в виде набора объектов и классов, связанных между собой родственными отношениями, а работа с объектами осуществляется с помощью скрытых (инкапсулированных) в них методов [1].
Объектно-ориентированная база данных (ООБД) – база данных, в которой данные оформлены в виде моделей объектов, включающих прикладные программы, которые управляются внешними событиями [18]. Результатом совмещения возможностей (особенностей) баз данных и возможностей объектно-ориентированных языков программирования являются Объектно-ориентированные системы управления базами данных (ООСУБД). ООСУБД позволяет работать с объектами баз данных так же, как с объектами в программировании в объектно-ориентированных языках программирования.
Объектно-ориентированные базы данных обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.
Примеры объектно-ориентированных СУБД: Cache, GemStone, ONTOS.
9.1.2.1.6. Объектно-реляционные
В последнее время производители СУБД стремятся соединить два этих подхода и проповедуют объектно-реляционную модель представления данных [1]. Примеры таких СУБД – IBM DB2 for Common Servers, Oracle 10, SQL Server 2008.
IT-блог о веб-технологиях, серверах, протоколах, базах данных, СУБД, SQL, компьютерных сетях, языках программирования и создание сайтов.
Сетевая база данных. Сетевая модель данных
Здравствуйте, уважаемые посетители моего скромного блога для начинающих вебразработчиков и web мастеров ZametkiNaPolyah.ru. Продолжаем рубрику Заметки о MySQL, в которой уже были публикации: Нормальные формы и транзитивная зависимость, избыточность данных в базе данных, типы и виды баз данных, настройка MySQL сервера и файл my.ini, MySQL сервер, установка и настройка, Архитектура СУБД и архитектура баз данных. Сегодня я бы хотел более подробно остановиться на сетевых базах данных, в общем-то, в одной из прошлых публикация я практически вскользь упоминал о них, но особой ясности не вносил. Следует сказать, что сетевая база данных относится к теоретико-графовым моделям, про то, что такое графы я постараюсь объяснить в другой публикации, сейчас этот момент не столь важен, но если хотите, то почитайте учебник математики. В этой публикации я постараюсь доступным и понятным языком рассказать о сетевых базах данных и принципе их работы, как обычно всю математику я сведу к минимуму и все умные термины оставлю за пределами данной публикации. Там, где я не смогу что-то объяснить без специфической терминологии, а такие моменты могут появиться, я все обязательно поясню.
Так вот, сетевые базы данных относятся к теоретико-графовым моделям баз данных, помимо сетевых баз данных сюда еще входят иерархические базы данных. Кстати, на основе математики сетевых баз данных существуют различные СУБД, это в основном коммерческие версии. У сетевых баз данных существуют характерные операции навигации, манипуляции и управления данными, с которыми мы и постараемся разобраться в данной публикации. Стоит сказать, что помимо теоретико-графовой модели баз данных существует еще и теоретико-множественная модель, к которой относятся реляционные базы данных, математика которых заложена в MySQL сервере, но до них мы еще обязательно дойдем. А теперь приступим к рассмотрению сетевой модели данных.
Сетевая модель данных
Прежде чем перейти к описанию процессов, которые происходят внутри сетевой модели данных, давайте ознакомимся со структурой сетевой базы данных, чтобы иметь представление о том, с чем предстоит иметь нам дело. Прежде всего, следует разобраться со словом сети, которое присутствует в название: «сетевая модель». Сети – это естественный способ представления отношений между объектами базы данных и связей между этими объектами. Под словом объекты следует понимать таблицы баз данных или сущности. В общем, как вам удобно, так и называйте, вас везде поймут правильно.
Сетевые базы данных опираются на математику графов, конкретнее, сетевую модель данных можно представить в виде ориентированного графа. Направленный граф состоит из узлов и ребер. Узлы направленного графа – это ни что иное, как объекты сетевой базы данных, а ребра такого графа показывают связи между объектами сетевой модели данных, причем ребра показывают не только саму связь, но и тип связи (связь один к одному или связь один ко многим). Взгляните на рисунок, чтобы лучше осознать суть написанного выше:
Структура сетевой базы данных, пример
Стоит заметить, что иерархическая модель баз данных является частным и упрощенным случаем сетевых баз данных.
Структура сетевых баз данных
Сетевые базы данных имеют достаточно простую структуру, во всяком случае, сетевая модель имеет более простую структуру, нежели реляционная модель. Структура сетевых баз данных состоит из четырех компонентов, то есть в сетевой модели используют четыре типа структур данных. Два из которых являются главными и два, если можно так сказать, не главными. Главные типы структур сетевых данных – это запись и набор. Вспомогательные типы структур сетевой модели данных, которые используются для построения главных структур – это элемент данных и агрегат данных. Сама структура сетевой базы данных выглядит так:
Сетевая модель данных, пример
Пять элементов структуры сетевой модели данных образуют саму базу данных. Теперь пройдемся по каждому из типов структуры сетевых баз данных.
Элемент данных – это наименьшая информационная именованная единица данных, доступная пользователю, если провести аналогию с файловой системой, то это поле в файловой системе, если проводит аналогию с реляционной базой данных, то элемент данных – один столбец таблицы реляционной БД. Если говорить точнее, то это подстолбец. Не знаю, как правильно выразиться, вообще, я косноязычен.
Агрегат данных – это следующий уровень обобщения данных сетевой модели. Агрегат данных – это именованная совокупность данных внутри одной записи. Аналогию с реляционными БД тут не проведешь, поскольку агрегат данных – это столбец над столбцами, который объединяет элементы данных по логике их содержимого, следующий рисунок внесет ясность во все выше написанное:
Агрегат данных сетевой модели данных
На данном рисунке видно, что дата – это агрегат данных структуры сетевой модели, а день, месяц и год – это элемент данных сетевой БД.
Запись в сетевой модели данных – это конечный уровень обобщения данных, что-то наподобие таблицы в реляционной базе данных. Каждая запись в сетевой базе данных должна обладать или содержать в себе, как минимум один именованный элемент данных, если элементов внутри записи более одного, то каждый элемент данных должен обладать уникальным форматом.
Давайте разбираться со структурой сетевых баз данных на примере, поскольку так будет более понятно и доступно. Представим, что мы хотим создать запись в сетевую базу данных, назовем ее скажем «Сотрудник», в которую обязательно должен входить агрегат данных, который представлен на рисунке выше, его мы назовем «Дата». В эту запись нам необходимо будет добавить: табельный номер, ФИО и адрес сотрудника. Выглядеть такая запись в сетеовой модели данных будет следующим образом:
Записей сетевой базы данных
Прежде, чем переходить к набору записей, нужно разобраться с тем, что такое тип записи и для чего нужен тип записи в сетевой базе данных. И так, тип записей – это совокупность логически связанных экземпляров записей. Проще сказать – это все записи, которые связаны между собой по смыслу и, которые дополняют друг друга. Если переложить термин тип записей на реальный мир, то это информационная модель (иначе, полное описание) какого-либо объекта из реального мира, например сотрудника фирмы.
Как видно из рисунка выше: в качестве элементов данных сетевой модели могут быть использованы только простые типы, если хотите данных, но это не совсем так. Потому что в качестве агрегатов данных можно использовать сложные типы. Сложные типы в структуре сетевых баз данных бывают двух видов: вектор и повторяющаяся группа. Агрегат типа вектор соответствует линейному набору элементов данных, такой агрегат вы уже видели, он называется у нас «Дата», ну это чтобы вы представляли себе, что такое линейный набор элементов данных.
Агрегат типа повторяющаяся группа – это совокупность векторов данных (то есть несколько векторов). Для большей ясности давайте представим новый агрегат данных, который назовем, ну скажем «Товар»:
Агрегат типа повторяющаяся группа
Товары обычно хранятся на складе или их продают, зачастую по нескольку штук. Я хочу подвести к тому, что агрегат типа повторяющаяся группа – это несколько агрегатов типа вектор, объединенных вместе, допустим, у нас покупают 5 товаров, значит, если наш агрегат «Товар» будет иметь тип повторяющаяся группа, то он будет состоять из 5 агрегатов типа вектор, примерно так.
Перейдем к дальнейшему рассмотрению структуры сетевой модели данных. Набор записей – это именованная двухуровневая иерархическая структура, которая содержит управляемую и управляющую записи. При помощи наборов указывается тип связи между записями. Что это означает? Проще говоря, набор это две записи, между которыми есть связь: один ко многим или один к одному. Представим, что у нас имеется две записи в сетевой базе данных: запись «Сотрудник», структуру которой я привел выше и запись «Отдел», структура которой в данном контексте нам не важна.
Перед нами стоит задача: осуществить логическую связь между двумя этими записями, то есть определить какая запись будет управляемой, а какая управляющей. Логично предположить, что запись «Отдел» должна быть управляющей, поскольку сотрудник работает в отделе, а не отдел в сотруднике. И понятно, что связь между этими записями должна быть один ко многим, потому что отдел один, а сотрудников много, назовем эту связь «Работает». И так, мы приходим к выводу, что набор записей сетевой модели данных определяет: управляющую запись, в нашем случае это «Отдел», подчиненную запись, которую мы назвали «Сотрудник», а так же тип связи между этими записями, которую мы обозвали «Работает». «Работает» — это не только имя связи, но еще и метка, которая именует сам набор данных сетевой модели. Впрочем, рисунок должны внести ясность в мои несколько путаные пояснения:
Набор записей сетевой модели данных
В данном случае связь один ко многим говорит нам о том, что с одним экземпляром записи «Отдел» может быть связано ноль, один или несколько экземпляров записи «Сотрудник». Экземпляр записи – это что-то наподобие кортежа (строки таблицы) из реляционной БД. Использую понятия сетевой модели данных, приведенные выше, можно нарисовать набор записей по-другому. На рисунке можно отобразить логические типы данных для обеих записей, структуру записей сетевой модели данных и указать связь между записями, которую мы обозвали «Работает»:
Теперь обобщим все то, что было написано выше про структуру сетевой базы данных, собственно обобщает все база данных. База данных сетевой модели данных – это именованная совокупность экземпляров записей различного типа и экземпляров наборов, хранящих в себе типы связей между записями. Проще говоря, это все записи и все связи между записями. Что же, мы познакомились со структурой сетевой модели данных, рассмотрели несколько примеров и заодно ознакомились с самыми простыми основами проектирования сетевых баз данных. Жаль, что я ничего не писал про концептуальное проектирование баз данных и концептуальную модель данных. В дальнейшем постараюсь исправить этот недостаток, потому что следующий раздел будет связан с концептуальной моделью.
Преобразование концептуальной модели в сетевую модель данных
На детальное рассмотрение концептуальное модели данных и концептуального проектирования баз данных может потребоваться пара публикаций, а ограничиваться общими словами я не хочу, поэтому сейчас, уважаемые посетители, я буду считать, что вы имеете представление о том, что такое концептуальная модель, если не знаете, то тут два выхода: либо вы ждете соответствующую публикацию на моем блоге, либо пользуетесь поисковыми системами. Думаю, на других сайтах люди пишут не хуже меня, а может быть и лучше. Если вы ничего не знаете про концептуальную модель данных, то смело пропускайте данный раздел.
Сетевую модель данных можно легко получить из концептуальной модели, причем нужно соблюсти всего лишь одно условие: в концептуальной модели данных должны использоваться только бинарные связи, которые принадлежат к типам: «один к одному» или «один ко многим». При этом вместо сущностей концептуальной модели данных следует использовать типы записей сетевой базы данных, собственно, имена сущностей из одной будут являться именами типов записей другой модели данных. Атрибуты, которые есть у сущностей (иначе столбцы таблицы) превращаются в поля записей сетевой модели данных, а связи между сущностями становятся связями между типами записей.
Бинарные связи концептуальной модели данных без затруднений переносятся на сетевую модель данных. Связь один ко многим переносится следующим образом: тип записи со стороны один становится управляющей записью, а тип записи со стороны многим становится подчиненной записью. Для связи один к одному запись владелец и подчиненная запись определяется произвольно.
Управление сетевыми данными
И последнее, о чем я бы хотел поговорить в этой публикации – управление сетевыми данными. Стоит сказать, что для манипулирования и управления данными в сетевой модели данных используется ряд типичных операций (о специфических операциях, присущих различным сетевым СУБД, мы говорить не будем), которые присущи для всех систем управления сетевыми базами данных. Все операции с сетевыми данными можно разделить на две группы: навигационные операции с данными и операции модификации данных.
Навигационные операции сетевых баз данных осуществляют переход по связям, определенных в схеме баз данных, в результате таких переходов определяется запись, которую называют текущей (запись сетевой модели, с которой мы будем работать). К навигационным операциям можно отнести:
При помощи операций модификации сетевых баз данных осуществляется добавление новых записей данных, добавление новых наборов данных, удаление записей данных и наборов записей, модификация агрегатов и элементов данных. Для реализации этих операций в системе текущее состояние детализируется путем запоминания трех его составляющих: текущего набора, текущего типа записи, текущего экземпляра типа записи. В такой ситуации возможны следующие операции:
Простое пособие по сетевой модели OSI для начинающих
Открытая сетевая модель OSI (Open Systems Interconnection model) состоит из семи уровней. Что это за уровни, как устроена модель и какова ее роль при построении сетей — в статье.
Модель OSI является эталонной. Эталонная она потому, что полное название модели выглядит как «Basic Reference Model Open Systems Interconnection model», где Basic Reference Model означает «эталонная модель». Вначале рассмотрим общую информацию, а потом перейдем к частным аспектам.
Принцип устройства сетевой модели
Сетевая модель OSI имеет семь уровней, иерархически расположенных от большего к меньшему. То есть, самым верхним является седьмой (прикладной), а самым нижним — первый (физический). Модель OSI разрабатывалась еще в 1970-х годах, чтобы описать архитектуру и принципы работы сетей передачи данных. Важно помнить, что данные передаются не только по сети интернет, но и в локальных сетях с помощью проводных или беспроводных соединений.
В процессе передачи данных всегда участвуют устройство-отправитель, устройство-получатель, а также сами данные, которые должны быть переданы и получены. С точки зрения рядового пользователя задача элементарна — нужно взять и отправить эти данные. Все, что происходит при отправке и приеме данных, детально описывает семиуровневая модель OSI.
На седьмом уровне информация представляется в виде данных, на первом — в виде бит. Процесс, когда информация отправляется и переходит из данных в биты, называется инкапсуляцией. Обратный процесс, когда информация, полученная в битах на первом уровне, переходит в данные на седьмом, называется декапсуляцией. На каждом из семи уровней информация представляется в виде блоков данных протокола — PDU (Protocol Data Unit).
Рассмотрим на примере: пользователь 1 отправляет картинку, которая обрабатывается на седьмом уровне в виде данных, данные должны пройти все уровни до самого нижнего (первого), где будут представлены как биты. Этот процесс называется инкапсуляцией. Компьютер пользователя 2 принимает биты, которые должны снова стать данными. Этот обратный процесс называется декапсуляция. Что происходит с информацией на каждом из семи уровней, как и где биты переходят в данные мы разберем в этой статье.
Первый, физический уровень (physical layer, L1)
Начнем с самого нижнего уровня. Он отвечает за обмен физическими сигналами между физическими устройствами, «железом». Компьютерное железо не понимает, что такое картинка или что на ней изображено, железу картинка понятна только в виде набора нулей и единиц, то есть бит. В данном случае бит является блоком данных протокола, сокращенно PDU (Protocol Data Unit).
Каждый уровень имеет свои PDU, представляемые в той форме, которая будет понятна на данном уровне и, возможно, на следующем до преобразования. Работа с чистыми данными происходит только на уровнях с пятого по седьмой.
Устройства физического уровня оперируют битами. Они передаются по проводам (например, через оптоволокно) или без проводов (например, через Bluetooth или IRDA, Wi-Fi, GSM, 4G и так далее).
Второй уровень, канальный (data link layer, L2)
Когда два пользователя находятся в одной сети, состоящей только из двух устройств — это идеальный случай. Но что если этих устройств больше?
Второй уровень решает проблему адресации при передаче информации. Канальный уровень получает биты и превращает их в кадры (frame, также «фреймы»). Задача здесь — сформировать кадры с адресом отправителя и получателя, после чего отправить их по сети.
У канального уровня есть два подуровня — это MAC и LLC. MAC (Media Access Control, контроль доступа к среде) отвечает за присвоение физических MAC-адресов, а LLC (Logical Link Control, контроль логической связи) занимается проверкой и исправлением данных, управляет их передачей.
На втором уровне OSI работают коммутаторы, их задача — передать сформированные кадры от одного устройства к другому, используя в качестве адресов только физические MAC-адреса.
Третий уровень, сетевой (network layer, L3)
На третьем уровне появляется новое понятие — маршрутизация. Для этой задачи были созданы устройства третьего уровня — маршрутизаторы (их еще называют роутерами). Маршрутизаторы получают MAC-адрес от коммутаторов с предыдущего уровня и занимаются построением маршрута от одного устройства к другому с учетом всех потенциальных неполадок в сети.
На сетевом уровне активно используется протокол ARP (Address Resolution Protocol — протокол определения адреса). С помощью него 64-битные MAC-адреса преобразуются в 32-битные IP-адреса и наоборот, тем самым обеспечивается инкапсуляция и декапсуляция данных.
Четвертый уровень, транспортный (transport layer, L4)
Все семь уровней модели OSI можно условно разделить на две группы:
Уровни группы Media Layers (L1, L2, L3) занимаются передачей информации (по кабелю или беспроводной сети), используются сетевыми устройствами, такими как коммутаторы, маршрутизаторы и т.п. Уровни группы Host Layers (L4, L5, L6, L7) используются непосредственно на устройствах, будь то стационарные компьютеры или портативные мобильные устройства.
Четвертый уровень — это посредник между Host Layers и Media Layers, относящийся скорее к первым, чем к последним, его главной задачей является транспортировка пакетов. Естественно, при транспортировке возможны потери, но некоторые типы данных более чувствительны к потерям, чем другие. Например, если в тексте потеряются гласные, то будет сложно понять смысл, а если из видеопотока пропадет пара кадров, то это практически никак не скажется на конечном пользователе. Поэтому, при передаче данных, наиболее чувствительных к потерям на транспортном уровне используется протокол TCP, контролирующий целостность доставленной информации.
Для мультимедийных файлов небольшие потери не так важны, гораздо критичнее будет задержка. Для передачи таких данных, наиболее чувствительных к задержкам, используется протокол UDP, позволяющий организовать связь без установки соединения.
При передаче по протоколу TCP, данные делятся на сегменты. Сегмент — это часть пакета. Когда приходит пакет данных, который превышает пропускную способность сети, пакет делится на сегменты допустимого размера. Сегментация пакетов также требуется в ненадежных сетях, когда существует большая вероятность того, что большой пакет будет потерян или отправлен не тому адресату. При передаче данных по протоколу UDP, пакеты данных делятся уже на датаграммы. Датаграмма (datagram) — это тоже часть пакета, но ее нельзя путать с сегментом.
Главное отличие датаграмм в автономности. Каждая датаграмма содержит все необходимые заголовки, чтобы дойти до конечного адресата, поэтому они не зависят от сети, могут доставляться разными маршрутами и в разном порядке. Датаграмма и сегмент — это два PDU транспортного уровня модели OSI. При потере датаграмм или сегментов получаются «битые» куски данных, которые не получится корректно обработать.
Первые четыре уровня — специализация сетевых инженеров, но с последними тремя они не так часто сталкиваются, потому что пятым, шестым и седьмым занимаются разработчики.
Пятый уровень, сеансовый (session layer, L5)
Пятый уровень оперирует чистыми данными; помимо пятого, чистые данные используются также на шестом и седьмом уровне. Сеансовый уровень отвечает за поддержку сеанса или сессии связи. Пятый уровень оказывает услугу следующему: управляет взаимодействием между приложениями, открывает возможности синхронизации задач, завершения сеанса, обмена информации.
Службы сеансового уровня зачастую применяются в средах приложений, требующих удаленного вызова процедур, т.е. чтобы запрашивать выполнение действий на удаленных компьютерах или независимых системах на одном устройстве (при наличии нескольких ОС).
Примером работы пятого уровня может служить видеозвонок по сети. Во время видеосвязи необходимо, чтобы два потока данных (аудио и видео) шли синхронно. Когда к разговору двоих человек прибавится третий — получится уже конференция. Задача пятого уровня — сделать так, чтобы собеседники могли понять, кто сейчас говорит.
Шестой уровень, представления данных (presentation layer, L6)
О задачах уровня представления вновь говорит его название. Шестой уровень занимается тем, что представляет данные (которые все еще являются PDU) в понятном человеку и машине виде. Например, когда одно устройство умеет отображать текст только в кодировке ASCII, а другое только в UTF-8, перевод текста из одной кодировки в другую происходит на шестом уровне.
Шестой уровень также занимается представлением картинок (в JPEG, GIF и т.д.), а также видео-аудио (в MPEG, QuickTime). Помимо перечисленного, шестой уровень занимается шифрованием данных, когда при передаче их необходимо защитить.
Седьмой уровень, прикладной (application layer)
Седьмой уровень иногда еще называют уровень приложений, но чтобы не запутаться можно использовать оригинальное название — application layer. Прикладной уровень — это то, с чем взаимодействуют пользователи, своего рода графический интерфейс всей модели OSI, с другими он взаимодействует по минимуму.
Все услуги, получаемые седьмым уровнем от других, используются для доставки данных до пользователя. Протоколам седьмого уровня не требуется обеспечивать маршрутизацию или гарантировать доставку данных, когда об этом уже позаботились предыдущие шесть. Задача седьмого уровня — использовать свои протоколы, чтобы пользователь увидел данные в понятном ему виде.
Протоколы здесь используют UDP (например, DHCP, FTP) или TCP (например, HTTP, HTTPS, SFTP (Simple FTP), DNS). Прикладной уровень является самым верхним по иерархии, но при этом его легче всего объяснить.
Критика модели OSI
Семиуровневая модель была принята в качестве стандарта ISO/IEC 7498, действующего по сей день, однако, модель имеет свои недостатки. Среди основных недостатков говорят о неподходящем времени, плохой технологии, поздней имплементации, неудачной политике.
Первый недостаток — это неподходящее время. На разработку модели было потрачено неоправданно большое количество времени, но разработчики не уделили достаточное внимание существующим в то время стандартам. В связи с этим модель обвиняют в том, что она не отражает действительность. В таких утверждениях есть доля истины, ведь уже на момент появления OSI другие компании были больше готовы работать с получившей широкое распространение моделью TCP/IP.
Вторым недостатком называют плохую технологию. Как основной довод в пользу того, что OSI — это плохая технология, приводят распространенность стека TCP/IP. Протоколы OSI часто дублируют другу друга, функции распределены по уровням неравнозначно, а одни и те же задачи могут быть решены на разных уровнях.
Разделение на семь уровней было скорее политическим, чем техническим. При построении сетей в реальности редко используют уровни 5 и 6, а часто можно обойтись только первыми четырьмя. Даже изначальное описание архитектуры в распечатанном виде имеет толщину в один метр.
Кроме того, в отличие от TCP/IP, OSI никогда не ассоциировалась с UNIX. Добиться широкого распространения OSI не получилось потому, что она проектировалась как закрытая модель, продвигаемая Европейскими телекоммуникационными компаниями и правительством США. Стек протоколов TCP/IP изначально был открыт для всех, что позволило ему набрать популярность среди сторонников открытого программного кода.
Даже несмотря на то, что основные проблемы архитектуры OSI были политическими, репутация была запятнана и модель не получила распространения. Тем не менее, в сетевых технологиях, при работе с коммутацией даже сегодня обычно используют модель OSI.
Вывод, роль модели OSI при построении сетей
В статье мы рассмотрели принципы построения сетевой модели OSI. На каждом из семи уровней модели выполняется своя задача. В действительности архитектура OSI сложнее, чем мы описали. Существуют и другие уровни, например, сервисный, который встречается в интеллектуальных или сотовых сетях, или восьмой — так называют самого пользователя.
Как мы упоминали выше, оригинальное описание всех принципов построения сетей в рамках этой модели, если его распечатать, будет иметь толщину в один метр. Но компании активно используют OSI как эталон. Мы перечислили только основную структуру словами, понятными начинающим.
Модель OSI служит инструментом при диагностике сетей. Если в сети что-то не работает, то гораздо проще определить уровень, на котором произошла неполадка, чем пытаться перестроить всю сеть заново.
Зная архитектуру сети, гораздо проще ее строить и диагностировать. Как нельзя построить дом, не зная его архитектуры, так невозможно построить сеть, не зная модели OSI. При проектировании важно учитывать все. Важно учесть взаимодействие каждого уровня с другими, насколько обеспечивается безопасность, шифрование данных внутри сети, какой прирост пользователей выдержит сеть без обрушения, будет ли возможно перенести сеть на другую машину и т.д. Каждый из перечисленных критериев укладывается в функции одного из семи уровней.