Создание информационно-справочной подсистемы САПР конструкторско-технологического назначения. Внешние соединители

/>

Рисунок 2.23 – Соединитель E-2000

Соединитель LC. В конце 1995 г. фирма LUCENT TECHNOLOGIES предложила новый ОС LC (Link-Control). В основе конструкции лежит традиционный способ юстировки волокон с наконечниками и центратором (рис. 2.24). Диаметр наконечника уменьшен до 1,25 мм, что позволило уменьшить габариты соединителя. Использование керамических наконечников позволило сохранить высокие параметры традиционных ОС. Дуплексность LC достигается попарной фиксацией коннекторов.

Рисунок 2.24 – Соединитель LC

Соединитель MU. Разработчик соединителя — компания NTT. Соединитель MU напоминает уменьшенный коннектор SC-типа (рис. 2.25). В конструкции использованы керамические наконечники типоразмера 1,25 мм. От коннектора SC этот тип ОС отличает также более простая конструкция и меньшее число деталей. Коннекторы и розетки MU могут объединяться в блоки до 16 соединителей и использоваться в качестве разъемного соединения печатных плат врубного типа.

Рисунок 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 обеспечивает описание предметной области на наиболее естественном языке: как классы, объекты и отношения между ними. Язык описания предметной области на данном этапе крайне важен: проектировщик анализирует и моделирует ее в обязательном контакте с пользователями, большинство из которых не являются техническими специалистами, поэтому для корректной интерпретации моделей язык их описания должен быть простым и понятным. На данном этапе моделирование осуществляется без привязки к конкретной СУБД.

На следующем этапе каноническая структура преобразуется в логическую структуру баз данных, которая учитывает ограничения выбранной СУБД. Рассмотрим особенности построения логических структур для объектно-ориентированных и реляционных СУБД.

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

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

Для адекватного моделирования сложных структур данных проектировщик должен иметь возможность определять свои типы данных, не ограничиваясь теми данными, которые предоставляются определенной реляционной СУБД. Реляционная модель не позволяет также определить набор операций, связанных с данными определенного типа, что часто является естественным требованием при моделировании объектов предметной области. Операции приходится задавать в конкретном приложении. Поэтому использование таких методов проектирования требует высокой квалификации проектировщиков.

В основе объектно-ориентированного подхода к моделированию предметных областей лежат такие понятия, как объект и свойства инкапсуляции, наследования и полиморфизма.

· Свойство инкапсуляции означает, что объекты имеют некоторую структуру и определенный набор операций, т.е. поведение. Внутренняя структура объекта скрыта от пользователя. Манипулирование объектом, изменение его состояния возможны лишь с помощью специальных методов, определяемых заданным набором операций.

· Свойство наследования позволяет создавать из объектов новые объекты. Они наследуют структуру и поведение своих предшественников, к которым добавляются характеристики, отражающие их индивидуальность.

· Свойство полиморфизма означает, что различные объекты могут получать одинаковые сообщения, но реагировать на них по-разному - в зависимости от того, каким образом в них реализованы методы реакции на сообщения.

Объектно-ориентированные технологии обеспечивают естественный переход от концептуальной структуры БД к логической структуре БД. В отличие от реляционных БД при проектировании объектно-ориентированных БД (ООБД) не требуется декомпозиция и нормализация объектов, выделенных на этапе концептуального проектирования. Объекты представляются в том же виде, что наделяет объектно-ориентированные структуры наглядностью и прозрачностью и позволяет значительно сократить время на их разработку и повысить степень преемственности. ООБД определяют возможность создания и использования сложных типов данных. При этом не требуется модификации ядра ООБД и для создания нового типа необходимо унаследовать характеристики любого имеющегося типа, наиболее подходящего по своему поведению и состоянию, расширить недостающие операции и атрибуты и переопределить уже имеющиеся. Полученные объектно-ориентированные структуры обладают высокой степенью модульности, что позволяет вносить в них изменения наиболее простым и безболезненным способом. При этом изменения влияют на один класс (или связанную подсистему классов) и могут эффективно управляться и проверяться. Развитые объектно-ориентированные СУБД содержат эффективные интерфейсы интеграции с известными инструментальными средствами проектирования, обеспечивающие автоматическую генерацию логической структуры и ее загрузку в ООБД. Например, СУБД Cache от компании InterSystems содержит интерфейс RoseLink, обеспечивающий тесную интеграцию с продуктом Rational Rose.

Рассмотрим этап разработки. Все множество запросов пользователей к БД можно разделить на два класса - множество запросов на модификацию данных и множество запросов на выборку данных. На этом этапе сложно сказать, какая структура - объектная или реляционная - наиболее предпочтительна. Простой, в то же время крайне эффективный и стандартизированный язык SQL обеспечивает наиболее удобные на данный момент механизмы для выборки и анализа данных и значительно превосходит по возможностям и удобству использования другие языки выборки и анализа данных. С другой стороны, объектно-ориентированные БД за счет поддержки сложных типов данных и отношений, механизмов свизлинга и двухэтапной фиксации данных предоставляют более развитые в сравнении с реляционными БД средства для работы с отдельными записями в БД. В отдельный класс запросов пользователей следует вынести задачи, связанные с массовой загрузкой, выгрузкой и обработкой данных. Данные задачи обычно выполняются в эксклюзивном режиме и часто требуют максимальной скорости выполнения. Известно, что максимальную скорость при работе с большими объемами данных обеспечивают иерархические базы данных. Таким образом, можно сделать вывод, что на этапе разработки выгодно использовать сразу три способа работы с данными. Что же делать? Создавать различные БД под управлением различных СУБД и регулярно их синхронизировать? Дорогое и очень сомнительное решение...

Последний этап - это этап развития системы. Безусловным лидером по удобству и скорости является объектный подход, который за счет реализации принципов наследования и полиморфизма обеспечивает наиболее простой и эффективный способ адаптации схемы БД в условиях изменяющихся требований пользователей.

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

В этой связи все большую популярность приобретают гибридные или постреляционные СУБД, которые реализуют сразу несколько моделей данных в рамках единого хранилища данных, а наиболее развитые - и в рамках единого хранилища метаданных.

На рынке представлено несколько гибридных СУБД от разных поставщиков. Условно их можно разделить на два класса. К первому относятся реляционно-объектные (объектно-реляционные) СУБД, в которых имеется объектная или реляционная надстройка над соответственно реляционной или объектной моделью данных. Эту модель активно продвигают традиционные поставщики реляционных СУБД.

Второй класс - постреляционные СУБД. Они не строятся ни на реляционной, ни на объектной модели, однако также позволяют представлять хранимые данные в виде как реляционных таблиц, так и классов объектов. К этому классу СУБД относится и СУБД Cache от компании InterSystems.

Обоим типам гибридных систем свойственны ненормализованная модель данных, инкапсулированная семантика приложений и множество внешних интерфейсов - как объектных, так и реляционных. Рассмотрим их особенности.

Объектная или реляционная надстройка над существующим ядром системы позволяет обойти часть ограничений, присущих ядру. Однако в этом случае складывается многоуровневая архитектура (рис.), что отрицательно влияет на производительность надстроек и утяжеляет само ядро системы. Кроме того, такая надстройка в большинстве случаев ограничена и не соответствует стандартам на реализацию модели (SQL92, SQL99) или рекомендациям комитетов по стандартизации (ODMG).

Сравнение Сache и реляционно-объектных архитектур

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

Основное отличие и преимущество постреляционных СУБД в сравнении с реляционно-объектными СУБД состоит в том, что в постреляционных СУБД механизмы работы с объектами и реляционными таблицами находятся на одном логическом уровне, что обеспечивает более высокую скорость доступа и работы с данными, функциональную полноту, в т.ч. соответствие определенным стандартам и спецификациям.

3.3 Реляционная структура данных

В конце 60-х годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как
отношение – relation (англ.)

Наименьшая единица данных реляционной модели – это отдельное
атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.

Доменом называется множество атомарных значений одного и того же типа. Так домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.

Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?

Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 3.2 приведен пример отношения для расписания движения самолетов

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

Рис. 3.2. Отношение с математической точки зрения (Ai - атрибуты, Vi - значения атрибутов)

Тело состоит из меняющегося во времени множества
кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Степень отношения "Рейс" – 8.

Кардинальное число или
мощность отношения – это число его кортежей. Мощность отношения "Рейс" равна 10. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.

2. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.

Каждое отношение обладает хотя бы одним возможным ключом, поскольку по меньшей мере комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами.

Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:

Отношение – Таблица (иногда Файл), Кортеж –
Строка (иногда Запись), Атрибут –
Столбец, Поле.

При этом принимается, что "запись" означает "экземпляр записи", а
"поле" означает "имя и тип поля".

3.4 Процедура проектирования

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

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

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

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

4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения.

5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством.

6. Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить описанную в п. 4.6 процедуру нормализации.

7. Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги.

8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.

На рис. 3.2 показан синтаксис предложения, предлагаемого для регистрации принимаемых проектных решений.

Рис. 3.3 Синтаксис описания проектных решений

Таблица 3.1 – Для примера приведем описания таблиц "Блюда" и "Состав"

СОЗДАТЬ ТАБЛИЦУ Блюда *( Стержневая сущность )ПЕРВИЧНЫЙ КЛЮЧ ( БЛ )ПОЛЯ ( БЛ Целое, Блюдо Текст 60, Вид Текст 7 )ОГРАНИЧЕНИЯ ( 1. Значения поля Блюдо должны бытьуникальными; при нарушении выводсообщения "Такое блюдо уже есть".2. Значения поля Вид должны принадлежатьнабору: Закуска, Суп, Горячее, Десерт,Напиток; при нарушении вывод сообщения"Можно лишь Закуска, Суп, Горячее,Десерт, Напиток");СОЗДАТЬ ТАБЛИЦУ Состав *( Связывает Блюда и Продукты )ПЕРВИЧНЫЙ КЛЮЧ ( БЛ, ПР )ВНЕШНИЙ КЛЮЧ ( БЛ ИЗ БлюдаNULL-значения НЕ ДОПУСТИМЫУДАЛЕНИЕ ИЗ Блюда КАСКАДИРУЕТСЯОБНОВЛЕНИЕ Блюда.БЛ КАСКАДИРУЕТСЯ)ВНЕШНИЙ КЛЮЧ ( ПР ИЗ ПродуктыNULL-значения НЕ ДОПУСТИМЫУДАЛЕНИЕ ИЗ Продукты ОГРАНИЧИВАЕТСЯОБНОВЛЕНИЕ Продукты.ПР КАСКАДИРУЕТСЯ)ПОЛЯ ( БЛ Целое, ПР Целое, Вес Целое )ОГРАНИЧЕНИЯ ( 1. Значения полей БЛ и ПР должны принадлежатьнабору значений из соответствующих полей таблицБлюда и Продукты; при нарушении вывод сообщения"Такого блюда нет" или "Такого продукта нет".2. Значение поля Вес должно лежать в пределахот 0.1 до 500 г. );

Рассмотренный язык описания данных, основанный на языке SQL [5], позволяет дать удобное и полное описание любой сущности и, следовательно, всей базы данных. Однако такое описание, как и любое подробное описание, не отличается наглядностью. Для достижения большей иллюстративности целесообразно дополнять проект инфологической моделью, но менее громоздкой.

Для наиболее распространенных реляционных баз данных можно предложить язык инфологического моделирования
"Таблица-связь", пример использования которого приведен на рис. 3.3. В нем все сущности изображаются одностолбцовыми таблицами с заголовками, состоящими из имени и типа сущности. Строки таблицы – это перечень атрибутов сущности, а те из них, которые составляют первичный ключ, распологаются рядом и обводятся рамкой. Связи между сущностями указываются стрелками, направленными от первичных ключей или их составляющих.

Рис. 3.4. Инфологическая модель базы данных "Питание", построенная с помощью языка "Таблицы-связи"

3.5 Характеристика связей и язык моделирования

При построении инфологических моделей можно использовать язык
ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможных представления такой связи:

Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи:

· множество связей между одними и теми же сущностями

(пациент, имея одного лечащего врача, может иметь также несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов);

· тренарные связи

(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);

· связи более высоких порядков, семантика (смысл) которых иногда очень сложна.

В приведенных примерах для повышения иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах. Так, ввод лишь нескольких основных атрибутов в описание брачных связей значительно усложнит ER-диаграмму (рис. 2.1,а). В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный
язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:

СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...](атрибут 1, атрибут 2, ..., атрибут n)

где S – степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания.

Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯИМ следующим образом:

Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)Пациент (Регистрационный_номер, Номер койки, Фамилия,Имя, Отчество, Адрес, Дата рождения, Пол)Лечащий_врач [Врач 1, Пациент M](Номер_врача, Регистрационный_номер)Консультант [Врач M,Пациент N](Номер_врача, Регистрационный_номер).

Рис. 3.5. Примеры ER-диаграмм

Для выявления связей между сущностями необходимо, как минимум, определить сами сущности. Но это не простая задача, так как в разных предметных областях один и тот же объект может быть сущностью, атрибутом или ассоциацией. Проиллюстрируем такое утверждение на примерах, связанных с описанием брачных связей (см. пример 2.1).

Пример 2.2. Отдел записей актов гражданского состояния (ЗАГС) имеет дело не со всеми людьми, а только с теми, кто обратился с просьбой о регистрации брака, рождения или смерти. Поэтому в странах, где допускаются лишь традиционные браки, отделы ЗАГС могут размещать сведения о регистрируемых браках в единственной сущности:

Брак (Номер_свидетельства, Фамилия_мужа, Имя_мужа,Отчество_мужа, Дата_рождения_мужа, Фамилия_жены,... , Дата_регистрации, Место_регистрации, ...),

ER-диаграмма которой приведена на рис. 2.1,б.

Пример 2.3. Теперь рассмотрим ситуацию, когда отдел ЗАГС расположен в стране, допускающей многоженство. Если для регистрации браков использовать сущность "Брак" примера 2.2, то будут дублироваться сведения о мужьях, имеющих несколько жен (см. табл. 2.1).

Таблица 2.1

Номер свидетельства	Фамилия мужа	...	Фамилия жены	...	Дата регистрации
1-ЮБ 154745	Петухов	...	Курочкина	...	06/03/1991
1-ЮБ 163489	Петухов	...	Пеструшкина	...	11/08/1991
1-ЮБ 169887	Петухов	...	Рябова	...	12/12/1992
1-ЮБ 169878	Селезнев	...	Уточкина	...	12/12/1992
1-ЮБ 154746	Парасюк	...	Свинюшкина	...	06/03/1991
1-ЮБ 169879	Парасюк	...	Хаврония	...	12/12/1992
...	...	...	...	...	...

Дублирование можно исключить созданием дополнительной сущности "Мужья"

Мужья (Код_М, Фамилия, Имя, Отчество, Дата рождения, Место рождения)

и заменой сущности "Брак" характеристикой (см. п. 2.3) со ссылкой на соответствующее описание в сущности "Мужья".

Брак (Номер свидетельства, Код_М, Фамилия жены, ...,Дата регистрации, ...){Мужья}.

ER-диаграмма связи этих сущностей показана на рис. 2.1,в, а пример их экземпляров в табл. 2.2 и 2.3.

Таблица 2.2

Код_М	Фамилия	Имя	Отчество	Год/р.	Место рожд.
111	Петухов	Альфред	Остапович	1971	г. Цапелька
112	Селезнев	Вавила	Абрамович	1973	г. Гусев
113	Парасюк	Гораций	Федулович	1972	г. Свиньин
...	...	...	...	...	...

Таблица 2.3

Номер свидетельства	Код_М	Фамилия жены	Имя жены	Дата регистрации	...
1-ЮБ 154745	111	Курочкина	Августина	06/03/1991	...
1-ЮБ 163489	111	Пеструшкина	Мариана	11/08/1991	...
1-ЮБ 169877	111	Рябова	Милана	12/12/1992	...
1-ЮБ 169878	112	Уточкина	Вероника	12/12/1992	...
1-ЮБ 154746	113	Свинюшкина	Эльвира	06/03/1991	...
1_ЮБ 169879	113	Хаврония	Руфина	12/12/1992	...
...	...	...	...	...	...

Пример 2.4. Наконец, рассмотрим случай, когда какой-либо организации потребовались данные о наличии в ней семейных пар, а для хранения сведений о сотрудниках уже имеется сущность

Сотрудники (Табельный_номер, Фамилия, Имя, ...).

Использование, рассмотренной в примере 2.2, сущности "Брак" нецелесообразно: в "Сотрудники" уже есть фамилии, имена, отчества супругов. Поэтому создадим ассоциацию

Брак [Сотрудник 1, Сотрудник 1](Табельный_номер_мужа, Табельный_номер_жены, ...),

связывающую между собой определенные экземпляры сущности "Сотрудники" (рис. 2.1,г).

В заключение отметим, что ER-диаграмма рис. 2.1,а описывает структуру размещения данных о браках в отделах ЗАГС стран, допускающих групповые браки, а ER-диаграммы примера 2.1, описания любых видов браков в организациях, где есть сущности "мужчины" и "женщины", включающие холостых и незамужних.

Что же такое "связь"? В ER-диаграммах это линия, соединяющая геометрические фигуры, изображающие сущности, атрибуты, ассоциации и другие информационные объекты. В тексте же этот термин используется для указания на взаимозависимость сущностей. Если эта взаимозависимость имеет атрибуты, то она называется ассоциацией.

ВЫВОДЫ

Технические характеристики оптических соединителей различных типов и разных производителей несколько отличаются, но все они лежат в определённых пределах.

В настоящее время в мире стандартизовано более 20 типов разъёмных оптических соединителей. Но на практике администрации связи различных стран останавливают свой выбор лишь на нескольких типах, так как наличие в сети связи соединителей разных типов может привести к сложностям при проведении измерений, вызовет необходимость использования гибридных адаптеров. Это усложнит эксплуатацию ВОЛС.

Разработали БД которая написана на VisualC++, версия 6,0. И приведена в приложении А.

ПЕРЕЧЕНЬ ССЫЛОК

1. Барабанов. С и др. Компьютерные сети: вчера, сегодня, завтра.// Компьютер Пресс - 1997- №2 - с. 152 - 158.

2. Клименко С., Уразметов В. Internet. Среда обитания информационного сообщества. Протвино, 1995.

3. Крол Э. Все об Internet. Киев, 1995.

4. Рамодин Д. Начальнику про Internet Мир ПК, 1998, № 8

5. Суханов А. Internet: первое знакомство. Мир ПК 1998 №3

стр. 124-130.

6. Фигурнов В.Е. IBM PC для пользователей. М:,ЮНИТИ,1997.

7. Журнал Компьютерра от 22 мая 2000г.

8. http://www.adp.ru/

9. Журнал «Сети и системы связи № 6». №11 сентябрь 1999. http://ccc.ru/magazine/depot/00_06/. «Пластиковое оптическое волокно на пути к домашним кабельным проводкам».

10. Основы волоконно-оптической связи, под ред. Е.М.Дианова, перевод с англ.