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

ЛИЧНЫЙ КАБИНЕТ 

 

Здравствуйте гость!

 

Логин:

Пароль:

 

Запомнить

 

 

Забыли пароль? Регистрация

Повышение уникальности

Предлагаем нашим посетителям воспользоваться бесплатным программным обеспечением «StudentHelp», которое позволит вам всего за несколько минут, выполнить повышение уникальности любого файла в формате MS Word. После такого повышения уникальности, ваша работа легко пройдете проверку в системах антиплагиат вуз, antiplagiat.ru, etxt.ru или advego.ru. Программа «StudentHelp» работает по уникальной технологии и при повышении уникальности не вставляет в текст скрытых символов, и даже если препод скопирует текст в блокнот – не увидит ни каких отличий от текста в Word файле.

Результат поиска


Наименование:


Шпаргалка Шпаргалка по "Программированию и компьютеру"

Информация:

Тип работы: Шпаргалка. Добавлен: 13.08.2012. Сдан: 2011. Страниц: 20. Уникальность по antiplagiat.ru: < 30%

Описание (план):


1.Данные и ЭВМ
Восприятие  реального мира можно соотнести  с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать  эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.
Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого.
Применение  ЭВМ для ведения* и обработки  данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Существует по крайней мере две исторические причины, по которым применение ЭВМ привело к отделению данных от интерпретации. Во-первых, ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке – основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ была первоначально весьма велика. Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая "знала", например, что шестое вводимое значение связано с временем прибытия самолета, а четвертое – с временем его вылета. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве.
Жесткая зависимость  между данными и использующими  их программами создает серьезные  проблемы в ведении данных и делает использования их менее гибкими.
Нередки случаи, когда пользователи одной и той  же ЭВМ создают и используют в своих программах разные наборы данных, содержащие сходную информацию. Иногда это связано с тем, что пользователь не знает (либо не захотел узнать), что в соседней комнате или за соседним столом сидит сотрудник, который уже давно ввел в ЭВМ нужные данные. Чаще потому, что при совместном использовании одних и тех же данных возникает масса проблем.
2Концепция  БД
Активная  деятельность по отысканию приемлемых способов обобществления непрерывно растущего  объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).
Основная  особенность СУБД – это наличие  процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием  хранимых в них данных и находящиеся под управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД).
Пусть, например, требуется хранить расписание движения самолетов (рис. 1.1) и ряд других данных, связанных с организацией работы аэропорта (БД "Аэропорт"). Используя для этого одну из современных "русифицированных" СУБД, можно подготовить следующее описание расписания:
СОЗДАТЬ ТАБЛИЦУ  Расписание
  (Номер_рейса        Целое
   Дни_недели         Текст (8)
   Пункт_отправления   Текст (24)
   Время_вылета       Время
   Пункт_назначения   Текст (24)
   Время_прибытия     Время
   Тип_самолета       Текст (8)
   Стоимость_билета   Валюта);
и ввести его  вместе с данными в БД "Аэропорт". 

Язык запросов СУБД позволяет обращаться за данными  как из программ, так и с терминалов (рис. 1.2). Сформировав запрос 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

3. Архитектура СУБД
СУБД должна предоставлять доступ к данным любым  пользователям, включая и тех, которые  практически не имеют и (или) не хотят  иметь представления о:
    физическом размещении в памяти данных и их описаний;
    механизмах поиска запрашиваемых данных;
    проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
    способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
    поддержании баз данных в актуальном состоянии
и множестве  других функций СУБД.
При выполнении основных из этих функций СУБД должна использовать различные описания данных.
проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД). в результате опроса АБД сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных.
Такая человеко-ориентированная  модель полностью независима от физических параметров среды хранения данныхОстальные  моделиявляются компьютеро-ориентированными. С их помощью СУБД дает возможность  программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.
Так как указанный  доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных.
Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.
4.Модели данных и основные типы СУБД
Как отмечалось в п. 1.3, инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д.
Инфологическая  модель должна быть отображена в компьютеро-ориентированную даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели
Сначала стали  использовать иерархические даталогические модели. Простота организации, наличие заранее заданных связей между сущностями, сходство с физическими моделями данных позволяли добиваться приемлемой производительности иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если данные не имели древовидной структуры, то возникала масса сложностей при построении иерархической модели и желании добиться нужной производительности.
Сетевые модели также создавались для мало ресурсных  ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" – поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база – это самый верный способ потерять данные".
Сложность практического  использования иерархических и  и сетевых СУБД заставляла искать иные способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.
Сегодня наиболее распространены реляционные модели, которые будут подробно рассмотрены в главе 3.
Физическая  организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Разнообразие способов корректировки физических моделей современных промышленных СУБД не позволяет рассмотреть их в этом разделе. 
 
 

5.CALS-технология понятие
Класс информационных технологий, направленных на обеспечение  безбумажной информационной поддержки  жизненного цикла продукта, именуется CALS-технологиями.
технологии  непрерывной информационной поддержки жизненного цикла продукции (CALS) позволяют:
решать различные  задачи, связанные с обработкой данных об изделии;
    создавать многовариантные документы (например, предназначенные для работы с гаммой или семейством изделий, имеющих отличия);
    обеспечивать доступ к содержимому документа в соответствии с категорией пользователя и уровнем допуска к документам;
    создавать многоязычные документы;
    использовать все стандартизованные способы представления информации (текстовая информация, изображения (растровые, векторные), аудио-, видеоинформация;
    проводить подготовку ИЭТР в универсальном виде, который позволяет различным пользователям использовать их без предварительной специальной обработки или адаптации.
    Этапы жизненного цикла
    Маркетинговые исследования
    Проектирование продукта
    Планирование и разработка процесса
    Закупка
    Производство или обслуживание
    Проверка
    Упаковка и хранение
    Продажа и распределение
    Монтаж и наладка
    Техническая поддержка и обслуживание
    Послепродажная деятельность
    Утилизация и(или) переработка
    7. Методологии и  средства системного  проектирования
(CASE-средства) составляют основу проекта любой  ИС. Методология реализуется через  конкретные технологии и поддерживающие  их стандарты, методики и инструментальные  средства, которые обеспечивают выполнение процессов ЖЦ.
Технология  проектирования определяется как совокупность трех составляющих:
· пошаговой  процедуры, определяющей последовательность технологических операций проектирования (рис. 1.4);
· критериев  и правил, используемых для оценки результатов выполнения технологических операций;
· нотаций (графических  и текстовых средств), используемых для описания проектируемой системы.
 
 
 
   
 
Технология  проектирования, разработки и сопровождения  ИС должна удовлетворять следующим общим требованям:
· технология должна поддерживать полный ЖЦ ПО;
· технология должна обеспечивать гарантированное  достижение целей разработки ИС с  заданным качеством и в установленное  время;
· технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части). Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций;
· технология должна обеспечивать возможность ведения  работ по проектированию отдельных  подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости  коллектива и повышения производительности за счет минимизации числа внешних связей;
· технология должна обеспечивать минимальное время  получения работоспособной ИС.
· технология должна обеспечивать независимость  выполняемых проектных решений  от средств реализации ИС операционных систем, языков и систем программирования;
· технология должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию  процессов, выполняемых на всех стадиях  ЖЦ. Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры  комплексов CASE-средств - в подразделе 5.7.
Реальное  применение любой технологии проектирования, разработки и сопровождения ИС в  конкретной организации невозможно без выработки ряда стандартов, которые  должны соблюдаться участниками  проекта.
· стандарт проектирования;
· стандарт оформления проектной документации;
· стандарт пользовательского  интерфейса.  
 
 
 

8. Предназначение IDEF1X
IDEF1X является  методом для разработки реляционных  баз данных и использует условный  синтаксис, специально разработанный  для удобного построения концептуальной схемы. Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы.
Сущность  в IDEF1X описывает собой совокупность или набор экземпляров похожих по свойствам, но однозначно отличаемых друх от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности. Таким образом, сущность в IDEF1X описывает конкретный набор экземпляров реального мира Примером сущности IDEF1X может быть сущность "СОТРУДНИК", которая представляет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, является конкретной реализацией этой сущности. В примере, приведенном на рис. 1, каждый экземпляр сущности СОТРУДНИК

Отношения многие ко многим обычно используются на начальной  стадии разработки диаграммы 
Идентификация сущностей. Представление  о ключах.
Сущность  описывается в диаграмме IDEF1X графическим  объектом в виде прямоугольника. На рис.2 приведен пример IDEF1X диаграммы. Каждый прямоугольник, отображающий собой сущность, разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены неключевые поля.
Ключевая  область содержит первичный ключ для сущности. Первичный ключ - это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности.
Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются мигрирующими.
Классификация сущностей в IDEF1X. Зависимые и независимые  сущности.
При разработке модели, зачастую, приходится сталкиваться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа.Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью.
Сущности, независящие  при идентификации от других объектов в модели, называются независимыми сущностями. В вышеописанном примере сущность ОТДЕЛ можно считать независимой. В IDEF1X независимые сущности представлены в виде прямоугольников.
Типы  связей между сущностями.
. Если вы  хотите, чтобы внешний ключ передавался в дочернюю сущность то можете создать идентифицирующую связь между родительской и дочерней сущность.
Идентифицирующие  взаимосвязи обозначаются сплошной линией между сущностями.
Неидентифицирующие  связи. Неидентифицирующие связи используются для отображения другого типа передачи атрибутов внешних ключей - передача в область данных дочерней сущности (под линией).
Преимущества IDEF1X
Основным  преимуществом IDEF1X, по сравнению с  другими многочисленными методами разработки реляционных баз данных, такими как ER и ENALIM является жесткая и строгая стандартизация моделирования. Установленные стандарты позволяют избежать различной трактовки построенной модели, которая несомненно является значительным недостатком ER.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

9. Основные понятия сущность ,атрибут…
Цель инфологического  моделирования – обеспечение  наиболее естественных для человека способов сбора и представления  той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.
Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:  
Красный, Синий, Банановый, Белая ночь и т.д., 
однако каждому экземпляру сущности присваивается только одно значение атрибута.

Абсолютное  различие между типами сущностей  и атрибутами отсутствует. Атрибут  является таковым только в связи  с типом сущности. В другом контексте  атрибут может выступать как  самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание (п. 1.2) ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой.  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

10. Характеристика связей 
При построении инфологических моделей можно использовать язык 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]
             (Номер_врача, Регистрационный_номер) 
 
 
 
 
 
 

11. ЯИМ
ввод лишь нескольких основных атрибутов в  описание брачных связей значительно  усложнит ER-диаграмму (рис. 2.1,а). В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:
СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)
АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...]
           (атрибут 1, атрибут 2, ..., атрибут n) 

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

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

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

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

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

12. . Классификация сущностей
К.Дейт [определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.
Стержневая  сущность (стержень) – это независимая сущность (несколько подробнее она будет определена ниже).
В рассмотренных  ранее примерах стержни – это "Студент", "Квартира", "Мужчины", "Врач", "Брак"
Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" ("1-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности). Ассоциации рассматриваются как полноправные сущности:
    они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;
    могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциации "Брак" из примеров 2.1 и 2.4 содержат ключевые атрибуты "Код_М", "Код_Ж" и "Табельный номер мужа", "Табельный номер жены", а также уточняющие атрибуты "Номер свидетельства", "Дата регистрации", "Место_регистрации", "Номер записи в книгу ЗАГС" и т.д.
Характеристическая  сущность (характеристика) – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Муж может иметь несколько жен (пример 2.3), книга – несколько характеристик переиздания (исправленное, дополненное, переработанное, ...) и т.д.
Существование характеристики полностью зависит  от характеризуемой сущности: женщины  лишаются статуса жен, если умирает  их муж.
Для описания характеристики используется новое  предложение ЯИМ, имеющее в общем  случае вид:
ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...)
               {СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.
Расширим  также язык ER-диаграмм, введя для  изображения характеристики трапецию (рис. 2.2).

Рис. 2.2. Элементы расширенного языка ER-диаграмм
Обозначающая сущность или обозначение – это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.
Рассмотрим  пример, связанный с зачислением  сотрудников в различные отделы организации.
При отсутствии жестких правил (сотрудник может  одновременно зачисляться в несколько  отделов или не зачисляться ни в один отдел) необходимо создать  описание с ассоциацией Зачисление:
Отделы (Номер  отдела, Название отдела, ...)
Служащие (Табельный  номер, Фамилия, ...)
Зачисление [Отделы M, Служащие N]
           (Номер отдела, Табельный номер,  Дата зачисления).
Однако, при  условии, что каждый из сотрудников  должен быть обязательно зачислен в  один из отделов, можно создать описание с обозначением Служащие:
Отделы (Номер  отдела, Название отдела, ...)
Служащие (Табельный  номер, Фамилия, ... , Номер отдела,
          Дата зачисления)[Отделы]
В данном примере  служащие имеют независимое существование (если удаляется отдел, то из этого  не следует, что также должны быть удалены служащие такого отдела). Поэтому они не могут быть характеристиками отделов и названы обозначениями.
Обозначения используют для хранения повторяющихся  значений больших текстовых атрибутов: "кодификаторы" изучаемых студентами дисциплин, наименований организаций и их отделов, перечней товаров и т.п.
Описание  обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные:
ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, ...)[СПИСОК
             ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].
Как правило, обозначения не рассматриваются  как полноправные сущности, хотя это  не привело бы к какой-либо ошибке. 
 
 
 
 
 
 
 
 
 
 
 

13. О первичных и  внешних ключах
ключ или возможный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты).
Не допускается, чтобы первичный ключ стержневой сущности (любой атрибут, участвующий  в первичном ключе) принимал неопределенное значение. Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью, и, следовательно не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность первичного ключа.
Теперь о  внешних ключах:
    Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.
    Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.
Связь между  первичными и внешними ключами сущностей  иллюстрируется рис. 2.5.
1. Может  ли данный внешний ключ принимать  неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? В случае поставок это, вероятно, невозможно – поставка, осуществляемая неизвестным поставщиком, или поставка неизвестного продукта не имеют смысла. Но в случае с сотрудниками такая ситуация однако могла бы иметь смысл – вполне возможно, что какой-либо сотрудник в данный момент не зачислен вообще ни в какой отдел. Заметим, что ответ на данный вопрос не зависит от прихоти проектировщика базы данных, а определяется фактическим образом действий, принятым в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют отношение и к вопросам, обсуждаемым ниже.
2. Что должно  случиться при попытке УДАЛЕНИЯ  целевой сущности, на которую  ссылается внешний ключ? Например, при удалении поставщика, который  осуществил по крайней мере  одну поставку. Существует три  возможности:
КАСКАДИРУЕТСЯ Операция удаления "каскадируется" с тем, чтобы удалить также поставки этого поставщика. ОГРАНИЧИВАЕТСЯ  Удаляются лишь те поставщики, которые  еще не осуществляли поставок. Иначе  операция удаления отвергается.
УСТАНАВЛИВАЕТСЯ Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.
Что должно происходить  при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:
КАСКАДИРУЕТСЯ Операция обновления "каскадируется" с тем, чтобы обновить также и  внешний ключ впоставках этого поставщика. ОГРАНИЧИВАЕТСЯ  Обновляются первичные ключи  лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
УСТАНАВЛИВАЕТСЯ Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается  в неопределенное значение, а затем  обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.
Таким образом, для каждого внешнего ключа в  проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на указанные выше вопроса (три ограничения, которые относятся к этому внешнему ключу).
Наконец, о  характеристиках – обозначающих сущностях, существование которых зависит от типа обозначаемых сущностей. Обозначение представляется внешним ключом в таблице, соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний ключ для данного случая должны специфицироваться следующим образом:
NULL-значения не допустимы
УДАЛЕНИЕ  ИЗ (цель) КАСКАДИРУЕТСЯ
ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ
Указанные спецификации представляют зависимость по существованию  характеристических сущностей. 
 

14.  Реляционная структура  данных
В конце 60-х  годов появились работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".
Будучи математиком  по образованию Э.Кодд предложил  использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) [3, 7, 9].
Наименьшая  единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.
Доменом называется множество атомарных значений одного и того же типа. Так, на рис. 1.1 домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.
Смысл доменов  состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют  смысл сравнения, использующие эти  два атрибута (например, для организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?
Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы  все они были различны) состоит  из заголовка и тела. На рис. 3.1 приведен пример отношения для расписания движения самолетов (рис. 1.1).
Заголовок (на рис. 1.1 он назывался интерпретацией) состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).  

Рис. 3.1. Отношение с  математической точки  зрения (Ai - атрибуты, Vi - значения атрибутов)
Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.
Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Степень отношения "Рейс" (рис. 1.1) – 8.
Кардинальное  число или мощность отношения – это число его кортежей. Мощность отношения "Рейс" равна 10. Кардинальное число отношения изменяется во времени в отличие от его степени.
Поскольку отношение  – это множество, а множества  по определению не содержат совпадающих  элементов, то никакие два кортежа  отношения не могут быть дубликатами  друг друга в любой произвольно-заданный момент времени. Пусть R – отношение  с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:
    Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
    Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.
Каждое отношение  обладает хотя бы одним возможным  ключом, поскольку по меньшей мере комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами.
Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:
Отношение –  Таблица (иногда Файл), 
Кортеж – Строка (иногда Запись), 
Атрибут – Столбец, Поле.

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

15.  Реляционная база  данных
Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц. Так на рис. 3.2 показаны таблицы базы данных, построенные по инфологической модели базы данных "Питание" рис. 2.4.
Рис. 3.2. База данных "Питание" (см. п. 2.3)
1. Каждая  таблица состоит из однотипных  строк и имеет уникальное имя.
2. Строки  имеют фиксированное число полей  (столбцов) и значений (множественные  поля и повторяющиеся группы  недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.
3. Строки  таблицы обязательно отличаются  друг от друга хотя бы единственным  значением, что позволяет однозначно  идентифицировать любую строку такой таблицы.
4. Столбцам  таблицы однозначно присваиваются  имена, и в каждом из них  размещаются однородные значения  данных (даты, фамилии, целые числа  или денежные суммы).
5. Полное  информационное содержание базы  данных представляется в виде явных значений данных и такой метод представления является единственным. В частности, не существует каких-либо специальных "связей" или указателей, соединяющих одну таблицу с другой. Так, связи между строкой с БЛ = 2 таблицы "Блюда" на рис. 3.2 и строкой с ПР = 7 таблицы продукты (для приготовления Харчо нужен Рис), представляется не с помощью указателей, а благодаря существованию в таблице "Состав" строки, в которой номер блюда равен 2, а номер продукта – 7.
6. При выполнении  операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Этому способствует наличие имен таблиц и их столбцов, а также возможность выделения любой их строки или любого набора строк с указанными признаками (например, рейсов с пунктом назначения "Париж" и временем прибытия до 12 часов). 

16. Манипулирование  реляционными данными
В главе 4 будет  показано, что стремление к минимизации  числа таблиц для хранения данных может привести к возникновению  различных проблем при их обновлении и будут даны рекомендации по разбиению некоторых больших таблиц на несколько маленьких. Но как сформировать требуемый ответ, если нужные для него данные хранятся в разных таблицах?
Предложив реляционную  модель данных, Э.Ф.Кодд создал и инструмент для удобной работы с отношениями – реляционную алгебру. Каждая операция этой алгебры использует одну или несколько таблиц (отношений) в качестве ее операндов и продуцирует в результате новую таблицу, т.е. позволяет "разрезать" или "склеивать" таблицы (рис. 3.3). 

Рис. 3.3. Некоторые операции реляционной алгебры
Созданы языки  манипулирования данными, позволяющие  реализовать все операции реляционной  алгебры и практически любые  их сочетания. Среди них наиболее распространены SQL (Structured Query Language – структуризованный язык запросов) и QBE (Quere-By-Example – запросы по образцу) [3, 5]. Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения.
С помощью  единственного запроса на любом  из этих языков можно соединить несколько  таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы (селекция и проекция). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

17. Цели проектирования
Только небольшие  организации могут обобществить данные в одной полностью интегрированной  базе данных. Чаще всего администратор  баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы). Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений. (Так в больших городах создается не одна, а несколько овощных баз, расположенных в разных районах.)
Отдельные БД могут объединять все данные, необходимые  для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, студентам, преподавателям, кулинарии и т.п.). Первые обычно называют прикладными БД, а вторые – предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями). (Первые можно сравнить с базами материально-технического снабжения или отдыха, а вторые – с овощными и обувными базами.)
Предметные  БД позволяют обеспечить поддержку  любых текущих и будущих приложений, поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без вынужденного переписывания старых приложений.
Основывая же проектирование БД на текущих и предвидимых  приложениях, можно существенно  ускорить создание высокоэффективной  информационной системы, т.е. системы, структура которой учитывает  наиболее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увеличивается число прикладных БД, резко возрастает уровень дублирования данных и повышается стоимость их ведения.
Таким образом, каждый из рассмотренных подходов к  проектированию воздействует на результаты проектирования в разных направлениях. Желание достичь и гибкости, и  эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной – для ее совершенствования с целью повышения эффективности обработки данных.
При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации) [2, 3, 4, 6, 8, 9, 10]. Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет – пассажир, преподаватель – дисциплина, студент – сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик – по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы.
Далее будут  рассматриваться вопросы, связанные с проектированием отдельных реляционных предметных БД.
Основная  цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект БД ("Каждый факт в одном месте") можно создать, используя методологию нормализации отношений. И хотя нормализация должна использоваться на завершающей проверочной стадии проектирования БД, мы начнем обсуждение вопросов проектирования с рассмотрения причин, которые заставили Кодда создать основы теории нормализации.
ниверсальное  отношение
Предположим, что проектирование базы данных "Питание" (рис. 3.2) начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 1/9/94 г.) показан на рис. 4.1.
Этот вариант  таблицы "Питание" не является отношением, так как большинство ее строк  не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р  остальные же поля таблицы рис. 4.1 – множественные. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан на рис. 4.2. Однако такое преобразование приводит к возникновению большого объема избыточных данных. 
 
 

18.  О нормализации, функциональных  и многозначных  зависимостях
Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Как указывалось  в п. 3.1, каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной (см. таблицы рис. 4.24.4). Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы (см. рис. 4.1), даже не допускаются в реляционной БД.
Всякая нормализованная  таблица автоматически считается  таблицей в первой нормальной форме, сокращенно 1НФ. Таким образом, строго говоря, "нормализованная" и "находящаяся в 1НФ" означают одно и то же. Однако на практике термин "нормализованная" часто используется в более узком смысле – "полностью нормализованная", который означает, что в проекте не нарушаются никакие принципы нормализации.
Теперь в  дополнение к 1НФ можно определить дальнейшие уровни нормализации – вторую нормальную форму (2НФ), третью нормальную форму (3НФ) и т.д. По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет, кроме того, некоторому дополнительному условию, суть которого будет рассмотрена ниже. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет еще другому дополнительному условию и т.д.
Таким образом, каждая нормальная форма является в  некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что "(N+1)-я нормальная форма" не обладает некоторыми непривлекательными особенностями, свойственным "N-й нормальной форме". Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей. В п. 4.3 мы выявляли непривлекательные особенности таблицы рис. 4.2 и для их исключения выполняли "интуитивную нормализацию".
Теория нормализации основывается на наличии той или  иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные.
Функциональная  зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Отметим, что здесь допускается, что поля А и В могут быть составными.
Например, в  таблице Блюда (рис. 4.4) поля Блюдо и Вид функционально зависят от ключа БЛ, а в таблице Поставщики рис. 4.3 поле Страна функционально зависит от составного ключа (Поставщик, Город). Однако последняя зависимость не является функционально полной, так как Страна функционально зависит и от части ключа – поля Город.
Полная  функциональная зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.
Многозначная  зависимость. Поле А многозначно определяет поле В той же таблицы, если для каждого значения поля А существует хорошо определенное множество соответствующих значений В.
Обучение 
Рис. 4.5. К иллюстрации  многозначных зависимостей
Для примера  рассмотрим таблицу "Обучение" (рис. 4.5). В ней есть многозначная зависимость "Дисциплина-Преподаватель": дисциплина (в примере Информатика) может  может читаться несколькими преподавателями (в примере Шипиловым и Голованевским). Есть и другая многозначная зависимость "Дисциплина-Учебник": при изучении Информатики используются учебники "Паскаль для всех" и "Язык Си". При этом Преподаватель и Учебник не связныфункциональной зависимостью, что приводит к появлению избыточности (для добавление еще одного учебника придется ввести в таблицу две новых строки). Дело улучшается при замене этой таблицы на две: (Дисциплина-Преподаватель и Дисциплина-Учебник).
и т.д.................


Перейти к полному тексту работы


Скачать работу с онлайн повышением уникальности до 90% по antiplagiat.ru, etxt.ru или advego.ru


Смотреть полный текст работы бесплатно


Смотреть похожие работы


* Примечание. Уникальность работы указана на дату публикации, текущее значение может отличаться от указанного.