Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Концептуальное проектирование баз данных

Концептуальное проектирование баз данных

Анализ моделирования данных как процесса создания логического представления структуры базы данных. Представление концептуальной модели средствами модели данных СУБД. Особенности использования ER-модели для концептуального проектирования базы данных.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 21.03.2017
Размер файла 432,6 K
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

30

Размещено на http://www.allbest.ru/

Курсовая работа

Дисциплина: Базы данных

Тема: Концептуальное проектирование баз данных

Кабанова Алексея Олеговича

Содержание

  • Введение
  • Основная часть
  • 1. Основные понятия концептуального проектирования баз данных
  • 2. Основные понятия ER-модели
  • 3. Представление концептуальной модели средствами модели данных СУБД
  • Заключение
  • Глоссарий
  • Список использованных источников
  • Приложения

Введение

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

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

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

Развитие Модели данных обычно включает три общие этапа.

Концептуальный - этот этап подразумевает идентификацию ключевых бизнес сущностей и системных сущностей и их взаимосвязей, которые определяют границы задач, решаемых системой. Эти ключевые бизнес сущности и системные сущности определяются с помощью элементов моделирования профайла UML для бизнес моделирования, включенного в модель бизнес анализа и элементов модели Класс анализа в модели анализа.

Логический - этот этап подразумевает детализацию ключевых бизнес сущностей и системных сущностей в более детальные логические сущности. Эти логические сущности и их взаимосвязи могут быть дополнительно определены в логической модели данных с помощью элементов моделирования профайла UML для проекта базы данных, как описано в руководстве Модель данных. Эта дополнительная Логическая модель является частью рабочего продукта Модель данных и не является отдельным рабочим продуктом.

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

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

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

· изучить основные понятия концептуального проектирования баз данных;

· выявить основные понятия ER-модели;

· рассмотреть представление концептуальной модели средствами модели данных СУБД.

Основная часть

1. Основные понятия концептуального проектирования баз данных

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

Таким образом, на данном этапе встает вопрос о построении некой семантической модели предметной области, отражающей необходимую информацию о выбранной предметной области. В качестве такого рода модели, широко используемой на этапе инфологического проектирования баз данных, является так называемая модель сущность-связь (Entity/Relationship Model), сокращенно - "ER-модель", предложенная в 1976 году Ченом. Чен П.П. Модель “сущность-связь" - шаг к единому представлению данных. СУБД, N3, 1995 г.

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

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

Любой выделенный объект-сущность предметной области характеризуются своими свойствами. Фактически начальное выделение в модели множества объектов-сущностей предметной области состоит в определении и выделении множества существенных свойств этих объектов.

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

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

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

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

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

Цель второй фазы проектирования базы данных состоит в создании логической модели данных для исследуемой части предприятия.

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

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

Концептуальное и логическое проектирование - это итеративные процессы, которые включают в себя ряд уточнений, продолжающиеся до тех пор, пока не будет получен наиболее соответствующий структуре предприятия продукт.

Моделирование реальности во многом похоже на решение ситуационной задачи. Нужно просеять детали и создать правильную модель части реальности. Тогда модель либо служит для решения задачи, либо все путает и портит. Существует три уровня модели Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М.: "Вильямс", 2006. - 1328 с. - ISBN 0-321-19784-4. :

· Низший - Иванов живет по адресу Площадь 15. Изменение адреса ведет к изменению данных.

· Средний - Имя, адрес.

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

Для единообразия программирования баз данных введены следующие понятия для концептуальных баз данных:

1. Объект или сущность. Это фактическая вещь или объект (для людей) за которой пользователь (заказчик) хочет наблюдать. Например, Иванов Иван Иванович;

2. Атрибут это характеристика объекта, соответствующая его сущности. Например. Задаем себе вопрос: Какую информацию нужно хранить об Иванове Иване Ивановиче? Ответы на этот вопрос и будут атрибуты объекта Иванов Иван Иванович;

3. Третье понятие в проектировании концептуальной базы данных это связь или отношения между объектами.

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

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

Диаграмма сущность/отношения (объект/связь) называют ER-диаграммой или EDR (entity-relationship diagram). Сама модель сущность-связь была предложена профессором Peter Pin-Shen Chen (Питер Чен) в 1976 году. Правила написания и условные обозначения ER-диаграммы называют нотацией. Распространены две основные нотации ER-диаграмм Коваленко, Т. Работа с базами данных. / Т. Коваленко, О. Сирант. - Электронный ресурс. URL: http: //www.intuit.ru/studies/courses/3439/681/lecture/14021. :

· Нотация Питера Чена;

· Нотация Gordon Everest (Гордона Эверста). Под назаванием Crow's Foot или Fork (вилка).

Чен предложил и это приняли следующие условные обозначения для ER-диаграмм:

· Сущность или объект обозначать прямоугольником;

· Отношения обозначать ромбом;

· Атрибуты объектов, обозначаются овалом;

· Если сущность связана с отношением, то их связь обозначается прямой линией со стрелкой.

· Необязательная связь обозначается пунктирной линией. Мощная связь обозначается двойной линией.

Каждый атрибут может быть связан с одним объектом (сущностью). Gordon Everest ввел новое обозначение связей, которые получили название вилка или воронья лапа. Также он ввел, что объект должен обозначаться прямоугольником с названием типа объекта в виде имени существительного внутри прямоугольника. Причем, это имя должно быть уникальным в пределах создаваемой базы данных. Атрибуты не выделяются в отдельную фигуру, а вписываются в прямоугольник объекта именем существительным с уточняющим словом. Связь между объектами обозначается прямой линией. Множественные связи обозначаются вилкой на конце. Сама связь подписывается глаголом, типа "Включает" или "Принадлежит".

Атрибуты в ER диаграмме, могут иметь свои собственные атрибуты (композитный) атрибут. Простую ER диаграмму нарисовать достаточно просто. Другое дело насыщенная, объемная ER диаграмма.

Простой атрибут состоит из одного компонента, его значение неделимо.

Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.

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

Многозначный атрибут - атрибут, который может иметь более одного значения для данного экземпляра сущности. Многозначный атрибут в модели Чена отображается как двойной овал.

Следует заметить, что многие начинающие проектировщики баз данных недооценивают важность семантического моделирования вручную. Зачастую это воспринимается как дополнительная и излишняя работа. Эта точка зрения является абсолютно неверной. Во-первых, построение мощной и наглядной концептуальной схемы БД позволяет более полно оценить специфику моделируемой предметной области и избежать возможных ошибок на стадии проектирования схемы реляционной БД. Во-вторых, на этапе семантического моделирования производится очень важная документация (хотя бы в виде вручную нарисованных диаграмм и комментариев к ним), которая может оказаться полезной не только при проектировании схемы реляционной БД, но и при эксплуатации, сопровождении и развитии уже заполненной БД. Кузнецов С.Д. Основы баз данных. - 2-е изд. - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с. - ISBN 978-5-94774-736-2.

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

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

2. Основные понятия ER-модели

Сущность-связь (ER) Модель основана на понятии реальных сущностей и связей между ними. Формулируя реального сценария в модель базы данных, ER Модель создает множество сущностей, набор отношений, общие атрибуты и ограничения.

Между двумя сущностями, возможны четыре вида связей. Зеленков, Ю.А. Введение в базы данных. // Электронный ресурс. URL: http: //www.mstu.edu.ru/study/materials/zelenkov/toc.html.

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

Студент может не получать стипендии, либо получать только одну стипендию.

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

В квартире может никто не жить или жить один или несколько жильцов.

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

Третий тип - многие ко многим.

Если связь между сущностями Квартира и Владелец называется Владение, то существует четыре возможных представления такой связи:

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

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

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

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

Теперь о внешних ключах Иванов К.К., Ефремов А.А., Ващенко И.А. Проектирование базы данных. Роль процесса в создании информационной системы // Молодой ученый. - 2016. - №18. - С. 40-42. :

Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

В таблице Издание поля ВидИздания и КодИздательства является внешним ключом, соответствующим внутренним ключам КодиВидИздания и КодИздательства таблиц ВидИздания и Издательства соответственно.

Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

Поле Ind1 таблицы Подчиненная является внешним ключом, соответствующим внутреннему ключу Ind таблицы Основная. Заметим, что таблица Подчиненная также имеет свой внутренний ключ Ind.

ER Модель лучше всего использовать для концептуального проектирования базы данных. ER Модель основана на:

· Объекты и их атрибуты.

· Отношения между субъектами.

Entity - Сущность в ER модель представляет собой реальный субъект, имеющий свойства называются атрибутами. Каждый атрибут определяется своим набором значений, называемых доменов. Например, в базе данных школы, студент рассматривается как единое целое. Студент имеет различные атрибуты, как имя, возраст, класс и т.д.

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

Mapping - кардинальность:

· один к одному

· один ко многим

· многие к одному

· многие ко многим

Другие свойства объектов, напротив, позволяют устанавливать общность между различными сущностями. Значения таких свойств позволяют осуществлять классификацию объектов, то есть объединять объекты, имеющие общие свойства, в определенные типы или классы объектов. Сами эти типы (классы) по своей сути также являются сущностями предметной области, но более абстрактными, обобщающими свойства некоторого множества экземпляров сходных объектов. Отношение между сущностью-классом и сущностью, являющейся экземпляром этого класса, называется отношением типа абстрактное-конкретное или общее-частное. Таким образом, на начальном этапе построения инфологической модели предметной области решаются следующие задачи Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. - 3-е изд. - М.: "Вильямс", 2003. - 1436 с. - ISBN 0-201-70857-4. :

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

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

· выделяются свойства, позволяющие объединять отдельные объекты (экземпляры) в абстрактные сущности, являющиеся классами или типами объектов.

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

Графически такое представление предметной области можно представить с помощью диаграммы, подобной представленной на рисунке 1 (См. Приложение А).

Как видно из рисунка, в приведенной предметной области выделено четыре сущности (типа сущностей): Студенты, Преподаватели, Факультеты и Дисциплины (на схеме обозначены прямоугольниками). Экземпляры, принадлежащие каждому из этих типов сущностей, характеризуются определенными наборами свойств (обозначены овалами). Набор свойств позволяет различать между собой типы выделенных сущностей. Экземпляры конкретных сущностей различаются между собой значениями их свойств. В общем случае каждый конкретный экземпляр может быть идентифицирован набором всех значений его свойств (в противном случае у нас просто не было бы никаких способов различить два экземпляра друг от друга). Однако обычно экземпляры сущности могут быть идентифицируемы не по полному набору значений ее свойств, а по части или даже по одному свойству. Такой набор свойств, позволяющий однозначно идентифицировать экземпляры сущности, называется идентификатором сущности или ее ключом.

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

На диаграмме, приведенной на рисунке 2 (См. Приложение Б), связи между объектами обозначены ромбами. Например, как показано на этой диаграмме, сущность (тип сущности) Студенты связана с сущностью Факультеты связью типа учится_на. Эта связь отражает тот факт данной предметной области, что конкретные студенты (экземпляры сущности Студенты) учатся на конкретных факультетах (экземплярах сущности Факультеты). Когаловский М.Р. Перспективные технологии информационных систем. - М.: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4.

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

Основные моменты этой модели:

· Данные хранятся в таблицах, называемых отношениями.

· Отношения могут быть нормализованы.

· В нормализации отношений, значения, сохраненные атомные значения.

· Каждая строка в отношении содержит уникальное значение.

· Каждый столбец в отношении содержит значения из одного домена.

Имеется четыре вида сущностей:

· Основная

· Характеристика

· Справочник

· Ассоциация

Основная сущность (стержень) - это независимая сущность. Характеристическая сущность (характеристика) - это связь вида "многие-к-одной" или "одна-к-одной" между двумя сущностями. Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства.

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

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

· Отделы (Номер отдела, Название отдела,.)

· Служащие (Табельный номер, Фамилия,.)

· Зачисление (Номер отдела, Табельный номер, Дата зачисления) [Отделы M, Служащие N]

В квадратные скобки помещены обозначения ключевых полей ассоциации.

Однако, при условии, что каждый из сотрудников должен быть обязательно зачислен в один из отделов, можно создать описание с обозначением Служащие:

· Отделы (Номер отдела, Название отдела,.)

· Служащие (Табельный номер, Фамилия,., Номер отдела, Дата зачисления) [Отделы]

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

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

Целостность (от англ. integrity - нетронутость, неприкосновенность, сохранность, целостность) - понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9, как день недели, явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1, 2, 3, 4, 5, 6,7). Коваленко, Т. Работа с базами данных. / Т. Коваленко, О. Сирант. - Электронный ресурс. URL: http: //www.intuit.ru/studies/courses/3439/681/lecture/14021.

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

Полезной модификацией классической ER-модели Чена является так называемая расширенная ER-модель (англ. Enhanced ER или EER). EER-модель включает все концепции ER-модели Чена плюс дополнительные концепции специализации и категоризации.

Последующие модификации ER-модели (нотации Баркера и IDEFiX), хоть и удостоились реализации в CASE-инструментах (Oracle Designer и ERwin соответственно), шли по пути сокращения выразительных возможностей представления семантики предметной области. Последняя модификация ER-модели (IDEF1X) отличается от реляционной модели, по сути, взаимнооднозначным переименованием понятий: "тип сущностей" - "отношение", "тип связей" - "ограничение ссылочной целостности", "атрибут типа сущностей" - "атрибут отношения".

3. Представление концептуальной модели средствами модели данных СУБД

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

Цель трехуровневой архитектуры заключается в отделении пользовательского представления БД от ее физического представления. Причины Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М.: "Вильямс", 2003. - 1088 с. - ISBN 5-8459-0384-X. :

· Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, реализуя свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей;

· Внутренняя структура БД не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения;

· Пользователи не должны непосредственно иметь дело с такими подробностями физического хранения данных в базе, как индексирование и хеширование. Иначе говоря, взаимодействие пользователя с базой не должно зависеть от особенностей хранения в ней данных;

· Администратор БД должен иметь возможность изменять структуру хранения данных в базе на свое усмотрение, не оказывая влияния на пользовательское представление;

· Администратор БД должен иметь возможность модернизировать концептуальную структуру БД без какого-либо влияния на всех пользователей.

Внешний уровень - представление данных с точки зрения пользователей. Этот уровень описывает пользователькую часть БД, т.е. часть, которая относится к каждому пользователю. Внешний уровень состоит из нескольких внешних представлений БД. Каждый пользователь имеет дело с представлением "реального мира", выраженным в наиболее удобной для него форме. Внешнее представление содержит только те сущности, атрибуты и связи, которые интересны пользователю. Другие сущности, атрибуты и связи, которые ему неинтересны, также могут быть представлены в БД, но пользователь может даже не подозревать об их существовании.

Концептуальный уровень - обобщающее преставление БД. Этот уровень описывает то, какие данные хранятся в БД, а также связи, существующие между ними. Этот уровень содержит логическую структуру всей БД (с точки зрения администратора БД). Фактически это полное представление требований к данным со стороны организации, которое не зависит от любых соображений относительно способа их хранения. На концептуальном уровне представлены следующие компоненты Анализ методов проектирования БД. // Shpargalum.ru. Электронный ресурс. URL: http: //shpargalum.ru/shpora-gos-povtas/proektirovanie-avtomatizirovannyix-sistem-na-osnove-bd/analiz-metodov-proektirovaniya-bd.html. :

· Все сущности, их атрибуты и связи;

· Накладываемые на данные ограничения;

· Семантическая информация о данных (связанная со значением, смыслом);

· Информация о мерах обеспечения безопасности и поддержки целостности данных.

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

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

· Распределение дискового пространства для хранения данных и индексов;

· Описание подробностей сохранения записей (с указанием реальных размеров сохраняемых элементов данных);

· Сведения о размещении записей;

· Сведения о сжатии данных и выбранных методах их шифрования.

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

Модель данных - абстрактное описание допустимых типов и структур данных, а также определенных на них отношений и операций. Три основные компоненты модели данных Когаловский М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4. :

· структура данных;

· набор допустимых операций над данными;

· ограничения целостности

1. Иерархическая модель данных - упорядоченная совокупность экземпляров типа "дерева". Тип "дерево" - иерархически организованный набор типов "запись". Основное правило целостности - между типами записей установлен тип отношений предок-потомок один-ко-многим, т.е. потомок имеет точно 1 родителя, у родителя может не быть потомков.

Иерархическая модель данных"+" простота организации, эффективное использование памяти ЭВМ для иерархической ПО, неплохая производительность даже на медленных ЭВМ.

"-" отсутствует явное разделение логических и физических характеристик модели; дублирование не иерархически организованных данных; непредвиденные запросы могут потребовать реорганизации базы данных.

2. Сетевая - расширение иерархического подхода. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков.

В сетевой модели существует две основные структуры данных:

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

Набор - отношение один-ко-многим между двумя типами записей (стрелки). Каждый набор состоит из типа записи предка, типа записи потомка и имени набора (метки, присвоенной стрелке).

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

"-" слабые возможности адаптации к изменяющимся требованиям; зависимость прикладного ПО от физической организации данных; сложность построения заранее не предвиденных запросов.

3. Реляционная - разработанная Э. Коддом в 1970г. логическая модель данных, описывающая:

· структуры данных в виде (изменяющихся во времени) наборов отношений;

· теоретико-множественные операции над данными: объединение, пересечение, разность и декартово произведение;

· специальные реляционные операции: селекция, проекция, соединение и деление; а также

· специальные правила, обеспечивающие целостность данных.

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

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

4. Постреляционная: снимает ограничение на неделимость данных, хранящихся в записях таблиц. Допускаются многозначные поля - поля, значения которых состоят из подзначений. Набор значений многозначных полей - отд. таблица, встроенная в основную. Не требуется операция join. Проблема целостности и непротиворечивости данных решается только средствами СУБД (по аналогии с процедурами в клиент-серверных моделях).

"+" можно представить несколько реляционных таблиц в одной постреляционной, увеличивается наглядность и эфф-ть обработки.

"-" проблема контроля целостности и непротиворечивости данных.

5. Многомерная (OLAP. online analytical processing, аналитическая обработка в реальном времени). Многомерное логическое представление структуры данных при их описании и в операциях над ними.

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

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

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

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

Историчность - неизменность самих данных, их взаимосвязей (статичность) и привязка ко времени (для удобства сортировки по времени).

Прогнозируемость - задание ф-й прогнозирования для различных временных интервалов.

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

Структура БД - дерево, узлы которого - объекты. Свойства объекта задаются стандартным типом или типом, конструируемым пользователем (class). Объект-экземпляр класса принадлежит своему классу и имеет одного родителя. Основное отличие от иерархической модели в методах манипулирования данными:

Инкапсуляция - свойство видно только в пределах того объекта, в котором оно определено.

Наследование - свойство видимо всем потомкам объекта.

Полиморфизм - один и тот же код может работать с разнотипными данными. Т.е. у объектов разных типов могут быть методы с одинаковыми именами.

"+" может отражать сложные связи между объектами, идентифицировать отдельные записи.

"-" неудобство обработки данных, низкая скорость выполнения запросов.

Заключение

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

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

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

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

· формализованность, обеспечивающую возможность автоматизированной обработки, в том числе, например, автоматический контроль непротиворечивости;

концептуальное проектирование база модель

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

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

· систему атрибутов и средств описания предметной области. Например, логические (автоматические) связи между показателями или лингвистические свойства языка (синонимию, синтаксис и т.д.), используемую для вербального представления объектов;

· ограничения целостности, определяющие допустимость значения отдельных полей и взаимосвязей как на уровне семантики содержимого БД, так и ее физической структуры (отдельных файлов данных и взаимосвязей между ними);

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

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

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

Моделирование отношения объектов - широко используемый метод моделирования, который используется для создания модели данных. Модель сущность-связь (ER-модель) предоставляет детализированное логическое представление бизнес-данных. Диаграмма сущность-связь (ERD) является коротким графическим представлением ER-модели.

Глоссарий

№ п/п

Понятие

Определение

1.

Архитектура информационной системы

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

2.

данные

это часть программы, совокупность значений определенных ячеек памяти, преобразование которых осуществляет код

3.

Защищенность информационной системы

Защищенность информационной системыспособность системы противостоять несанкционированному доступу к конфиденциальной информации, ее искажению или разрушению. Различают два аспекта защищенности:

1 - техническую защиту (свойство недоступности); и

2 - социальную защищенность (свойство конфиденциальности)

4.

Лисп

(LISP, от англ. LISt Processing - "обработка списков"; современное написание: Lisp) - семейство языков программирования, программы и данные в которых представляются системами линейных списков символов

5.

Методы управления

совокупность способов и средств воздействия управляющего субъекта на объект управления для достижения определенных целей.

6.

Принципы управления

правила, которыми руководствуются субъекты управления.

7.

семантическая сеть

В семантической сети понятия и классы, а также отношения и связи между ними представлены в виде поименованного графа. Каждый узел содержит ссылку на один или несколько других узлов

8.

Символ

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

9.

системный анализ

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

10.

Функциональная подсистема

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

Список использованных источников

1. Анализ методов проектирования БД. // Shpargalum.ru. Электронный ресурс. URL: http://shpargalum.ru/shpora-gos-povtas/proektirovanie-avtomatizirovannyix-sistem-na-osnove-bd/analiz-metodov-proektirovaniya-bd.html.

2. Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М.: "Вильямс", 2006. - 1328 с. - ISBN 0-321-19784-4.

3. Зеленков, Ю.А. Введение в базы данных. // Электронный ресурс. URL: http://www.mstu.edu.ru/study/materials/zelenkov/toc.html.

4. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М.: "Вильямс", 2003. - 1088 с. - ISBN 5-8459-0384-X.

5. Иванов К.К., Ефремов А.А., Ващенко И.А. Проектирование базы данных. Роль процесса в создании информационной системы // Молодой ученый. - 2016. - №18. - С.40-42.

6. Коваленко, Т. Работа с базами данных. / Т. Коваленко, О. Сирант. - Электронный ресурс. URL: http://www.intuit.ru/studies/courses/3439/681/lecture/14021.

7. Когаловский М.Р. Перспективные технологии информационных систем. - М.: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4.

8. Когаловский М.Р. Энциклопедия технологий баз данных. - М.: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4.

9. Кузнецов С.Д. Основы баз данных. - 2-е изд. - М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. - 484 с. - ISBN 978-5-94774-736-2.

10. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. - 3-е изд. - М.: "Вильямс", 2003. - 1436 с. - ISBN 0-201-70857-4.

11. Коваленко, Т. Работа с базами данных. / Т. Коваленко, О. Сирант. - Электронный ресурс. URL: http://www.intuit.ru/studies/courses/3439/681/lecture/14021.

12. Чен П.П. Модель “сущность-связь" - шаг к единому представлению данных. СУБД, N3, 1995 г.

Приложения

Приложение А

Схема 1.

Приложение Б

Схема 2.

Размещено на Allbest.ru

...

Подобные документы

  • Проектирование базы данных библиотеки

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

    контрольная работа [784,2 K], добавлен 10.04.2014

  • Создание базы данных для паспортно-визовой службы

    Построение концептуальной модели, процесс моделирования смыслового наполнения базы данных. Основные компоненты концептуальной модели. Построение реляционной модели. Целостность данных в реляционной базе. Нормализация. Проектирование базы данных в ACCESS.

    курсовая работа [1,8 M], добавлен 29.10.2008

  • Принципы построения и проектирования базы данных

    Понятие информации, автоматизированных информационных систем и банка данных. Общая характеристика описательной модели предметной области, концептуальной модели и реляционной модели данных. Анализ принципов построения и этапы проектирования базы данных.

    курсовая работа [1,7 M], добавлен 18.01.2012

  • Спортивная программа и организация базы данных

    Составление схемы концептуальной модели данных. Разработка структуры реляционной базы данных и интерфейса пользователя. Особенности главных этапов проектирования базы данных. Способы реализации запросов и отчетов. Специфика руководства пользователя.

    курсовая работа [186,9 K], добавлен 18.12.2010

  • Проектирование базы данных "Книжный каталог"

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

    курсовая работа [838,9 K], добавлен 25.11.2010

  • Проектирование базы данных туристического агентства

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

    курсовая работа [1,4 M], добавлен 14.01.2018

  • Разработка базы данных "Автомобильное предприятие"

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

    курсовая работа [981,4 K], добавлен 05.11.2011

  • Базы данных

    Сущность базы данных. Процесс построения концептуальной модели. Построение реляционной модели, создание ключевого поля. Процесс нормализации. Проектирование базы данных в ACCESS. Порядок создание базы данных. Создание SQL запросов и работа в базе данных.

    курсовая работа [185,6 K], добавлен 08.11.2008

  • Проектирование базы данных для ДЮСШ

    Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.

    курсовая работа [1,7 M], добавлен 04.06.2015

  • База данных: подсистема "ЗАГС"

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

    курсовая работа [2,1 M], добавлен 08.06.2012

  • Базы данных

    Система управления базами данных (СУБД). Программные средства, предназначенные для создания, наполнения, обновления и удаления базы данных. Структура, модели и классификация баз данных. Создание каталогов, псевдонимов, таблиц, шаблонов и форм СУБД.

    презентация [1,1 M], добавлен 09.01.2014

  • Принципы создания база данных "Художники ВКО"

    Этап концептуального проектирования базы данных: описание и характеристика предметной области, ограничения и допуения, модель "сущность-связь" (ER-диаграмма). Выбор модели данных. Требования к интерфейсу пользователя, создание запросов в среде Delphi.

    курсовая работа [2,2 M], добавлен 25.05.2010

  • Базы и банки данных

    Понятия банка и базы данных, ее компоненты. Многоуровневые модели предметной области, их представление в базе данных. Идентификация объектов и записей. Способы обращения к записям или отдельным элементам данных, их поиск. Определение структуры данных.

    контрольная работа [39,6 K], добавлен 10.04.2010

  • АИС для ГОУДОД Центра развития творчества детства и юношества

    Процесс разработки структуры базы данных по требованиям заказчиков. Основные задачи инфологического, концептуального и логического проектирования, средства создания модели. Этапы выполнения проектирования баз данных для Центра развития творчества.

    курсовая работа [33,3 K], добавлен 10.06.2011

  • Логическое проектирование баз данных

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

    курсовая работа [188,6 K], добавлен 15.07.2012

  • Разработка базы данных для хранения информации, необходимой для организации предоставления услуг

    Разработка информационно-аналитической системы агентства недвижимости. Обоснование выбора архитектуры базы данных и СУБД. Моделирование потоков данных (DFD диаграмм). Проектирование инфологической модели данных с использованием модели "сущность-связь".

    дипломная работа [5,4 M], добавлен 06.06.2013

  • Проектирование и реализация базы данных в архитектуре "клиент-сервер"

    Ограничения, присутствующие в предметной области. Проектирование инфологической модели данных. Описание основных сущностей и их атрибутов. Логический и физический уровни модели данных. Реализация базы данных: представления, триггеры, хранимые процедуры.

    курсовая работа [1,7 M], добавлен 10.02.2013

  • Наращивание экономической и статистической информации в двухструктурных реляционных базах данных

    Эволюция концепций баз данных. Требования, которым должна удовлетворять организация базы данных. Модели представления данных. Язык SQL как стандартный язык баз данных. Архитектуры баз данных. Среда Delphi как средство для разработки СУБД.

    дипломная работа [278,9 K], добавлен 26.11.2004

  • Проектирование базы данных "Книжный магазин"

    Реализация приложения "Книжный магазин" средствами систем управления базами данных. Проектирование структуры базы данных, определение сущности и атрибутов. Логическое проектирование базы данных и реализация базы данных в СУБД Microsoft Office Access.

    курсовая работа [7,8 M], добавлен 13.02.2023

  • Проектирование базы данных для автоматизированной системы

    Проектирование базы данных для автоматизированной системы "Склад". Разработка концептуальной модели (ER-диаграмма). Преобразование в реляционную модель и ее нормализация. Разработка запросов к базе данных на языке SQL. Скрипт для создания базы данных.

    курсовая работа [161,8 K], добавлен 07.10.2013

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены