Создание информационно-справочной подсистемы САПР конструкторско-технологического назначения. Внешние соединители (стр. 5 из 8)
Рисунок 2.25 – Соединитель MU
Соединитель LX.5 (рис. 2.26). Разработчик — фирма ADC TELECOMMUNICATION. В ОС LX.5 используется керамический наконечник диаметром 1,25 мм. Коннектор имеет защитную крышку. Дуплексная LX.5 розетка имеет форм-фактор одиночной розетки SC.
Рисунок 2.26 – Соединитель LX
Соединитель MT-RJ (рис. 2.27) был совместно разработан компаниями AMP, FUJIKURA, HEWLET PACKARD (AGILENT TECHNOLOGIES), SIECOR и US CONEC и появился на рынке в 1997 г. В основу ОС был положен прямоугольный пластиковый наконечник соединителя MT, разработанный ранее компанией NTT. Коннектор MT-RJ — дуплексный, по конструктиву максимально приближен к коннектору RJ-45. Достоинством ОС MT-RJ является отсутствие в них таких дорогостоящих деталей, как керамический наконечник и центратор в розетке. Соединители MT-RJ следует считать преимущественно многомодовыми, поскольку дуплексный пластиковый феррул приводит к ухудшению такого важного для одномодовых ОС параметра, как уровень обратного отражения. Тем не менее поставляются и одномодовые компоненты MT-RJ.
Рисунок 2.27 – Соединитель MT-RJ
Соединитель VF-45 был разработан компанией 3M в составе полностью оптической СКС 3M Volition. Соединитель VF-45 (рис. 2.28) дуплексный, конструктивно близок к RJ-45. Поперечная фиксация волокон в коннекторе обеспечивается V-канавками. Отсутствие дорогостоящих феррулов и центраторов обеспечивает низкую стоимость соединителя. На базе 3M Volition наиболее экономично реализуется концепция “волокно до рабочего места” (fiber to the desk). К недостаткам ОС можно отнести невысокие параметры по вносимым потерям и уровню обратного отражения, а также их низкую стабильность.
Рисунок 2.28 – Соединитель VF-45
Таблица 2.6 Некоторые параметры основных типов малогабаритных оптических соединителей
3. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННО-СПРАВОЧНОЙ ПОДСИСТЕМЫ САПР КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКОГО НАЗНАЧЕНИЯ
3.1 Проектирование хранилища данных
Рисунок 3.1- Состав и взаимосвязь задач работы «Проектирование данных хранилища»
При разработке ER-модели необходимо помнить, что это наиболее общий вид модели, с которым имеет дело разработчик – в том смысле, что модели этого вида практически не привязаны к компьютерным реалиям (абстрагированы от них). Это «понятийная модель», модель понятий предметной области. Таким образом, при разработке ER-модели проектируется схема понятий прикладной области в их взаимосвязи.
Основными понятиями ER-модели являются сущность, связь и атрибут.
Сущность - это реальный или представляемый объект, информация о котором должна сохраняться и быть доступна. Имя сущности - это имя класса, а не некоторого конкретного экземпляра этого класса. Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных объектов этого типа. Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.
Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).
Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности.
Уникальным идентификатором сущности является атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа.
Сущность может быть расщеплена на два или более взаимно исключающих подтипа, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи. В принципе подтипизация может продолжаться на более низких уровнях, но опыт показывает, что в большинстве случаев оказывается достаточно двух-трех уровней.
Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т.е. любой экземпляр супертипа должен относиться к некоторому подтипу.
ER-модель - это модель понятий предметной области в их взаимосвязи, и иерархии среди этих объектов.
После того, как будет сформирована ER-модель, разработчик хранилища данных разрабатывает реляционную и физическую модели данных.
Реляционная модель данных представляет собой трансформацию ER-модели и описывает следующие элементы проектирования:
описание таблиц, столбцов и представлений, описания первичных, уникальных и внешних ключей, правила по уровням валидации столбцов и строк (ограничения проверок), правила заполнения отдельных столбцов (последовательность, источники).Разработка реляционной модели ведется на основе ER-модели с учетом особенностей выбранного типа базы данных. В отличие от построения ER-модели, построение реляционной модели несет в себе сравнительно малую семантическую нагрузку, и часто понимается уже как «логическое моделирование базы данных» (а не прикладной области). В таком понимании цель его состоит в том, чтобы описать базу данных безотносительно к конкретной СУБД (считается, что проектируется как бы «логически одна» база данных для всего хранилища данных ИАС). Основная цель разработки реляционной модели - сформировать домены, их атрибуты и взаимосвязи с учетом требований постановки задачи и независимости данных (а они могут противоречить друг другу).
Физическая модель данных описывает структуры хранения данных с использованием всех особенностей конкретной СУБД. Она непосредственно учитывает такие аспекты, как архитектуру, безопасность, эффективность доступа и другие.
Результат выполнения работы «Проектирование данных хранилища»
В результате выполнения этой работы формируется модель хранилища данных, включающая в себя следующие артефакты, «ER-модель», «Реляционная модель данных», «Физическая модель данных».
ER-модель - это модель объектов предметной области в их взаимосвязи, и иерархии среди этих объектов.
Реляционная модель данных описывает следующие элементы проектирования хранилища данных:
таблицы, столбцы и представления, первичные, уникальные и внешние ключи, правила по уровням валидации столбцов и строк (ограничения проверок), правила заполнения отдельных столбцов (последовательность, источники).Физическая модель представляет собой SQL скрипт, позволяющий создать реальную базу данных. В ряде случаев может потребоваться также включить в физическую модель описание дополнительных настроек СУБД, необходимых для реализации БД.
Физическая модель данных содержит следующую информацию:
описание базы данных, сегментов отката и табличных областей, описания файлов и структуры памяти, типы индексов, описания объектов, связанных с хранилищем данных (физическое размещение, включая сегментацию).3.2 Особенности проектирования современных баз данных
Современные объемы хранимых данных, обязательные требования к их доступности и скорости обработки, динамика развития систем обуславливают важность исследования факторов, влияющих на качество баз данных (БД), лежащих в основе современных информационных систем.
Обычно жизненный цикл БД включает в себя этапы концептуального и логического проектирования, разработки, сопровождения и развития. Рассмотрим каждый этап.
На этапе концептуального проектирования анализируются свойства и характеристики исследуемой предметной области и формируются канонические структуры баз данных, обычно представляемые в виде графов, узлами которых являются объекты предметной области, а дугами - отношения между ними. Для описания канонической структуры базы данных используются разные технологии и инструментальные средства, например Rational Rose и реализованная в нем нотация UML (Unified Modeling Language - унифицированный язык моделирования). UML обеспечивает описание предметной области на наиболее естественном языке: как классы, объекты и отношения между ними. Язык описания предметной области на данном этапе крайне важен: проектировщик анализирует и моделирует ее в обязательном контакте с пользователями, большинство из которых не являются техническими специалистами, поэтому для корректной интерпретации моделей язык их описания должен быть простым и понятным. На данном этапе моделирование осуществляется без привязки к конкретной СУБД.