2.Технологія fddi (середовище передачі інформації, основні технічні характеристики, метод доступу).

FDDI (англ. Fiber Distributed Data Interface — Волоконно-оптический интерфейс по распределенным данным) — стандарт передачи данных в локальной сети, протянутой на расстоянии до 200 километров. Стандарт основан на протоколе Token Ring. Кроме большой территории, сеть FDDI способна поддерживать несколько тысяч пользователей. В качестве среды передачи данных в FDDI рекомендуется использовать волоконно-оптический кабель, однако можно использовать и медный кабель, в таком случае используется сокращение CDDI (Copper Distributed Data Interface). В качестве топологии используется схема двойного кольца, при этом данные в кольцах циркулируют в разных направлениях. Одно кольцо считается основным, по нему передаётся информация в обычном состоянии; второе — вспомогательным, по нему данные передаются в случае обрыва на первом кольце. Для контроля за состоянием кольца используется сетевой маркер, как и в технологии Token Ring. Поскольку такое дублирование повышает надёжность системы, данный стандарт с успехом применяется в магистральных каналах связи. Основные технические характеристики сети FDDI следующие:Максимальное количество абонентов сети — 1000. Максимальная протяженность кольца сети - 20 км. Максимальное расстояние между абонентами сети - 2 км. Среда передачи - многомодовый оптоволоконный кабель (возможно применение электрической витой пары). Метод доступа - маркерный. Скорость передачи информации — 100 Мбит/с (200 Мбит/с для дуплексного режима передачи). Предусмотрена также возможность применения одномодового кабеля, и в этом случае расстояние между абонентами может достигать 45 километров, а полная длина кольца - 100 километров. Для передачи данных в FDDI применяется код 4В/5В, специально разработанный для этого стандарта. Он обеспечивает скорость передачи 100 Мбит/с при пропускной способности кабеля 125 миллионов сигналов в секунду (или 125 МБод), а не 200 МБод, как в случае кода Манчестер-П.

3.Проектування реляційних баз даних. Проектування реляційних бд із використанням нормалізації.

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

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

4.Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения. 5.Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством. 6.Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги. 8.Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей