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

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

Министерство образования и науки РФ ФГБОУ ВО «Волгоградский государственный архитектурно-строительный университет»

Кафедра МиЕНд

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

по дисциплине: «Архитектура информационных систем»

на тему: «Модели данных, как инструментальные средства на этапах проектирования базы данных»

Выполнил:

Студент гр. ИСТ-11д Куркин Е. В.

Проверил:

ст. преподаватель Гусенко Н. С.

Михайловка, 2016г.



Содержание

Введение

1. Модели данных, как инструментальные средства на этапах проектирования базы данных

1.1 Базы данных. Структура и типы данных

1.1.1 Зачем нужны базы данных

1.1.2 Типы и структуры данных

1.1.3 Обобщенные структуры или модели данных

1.2 Модель "сущность-связь"

1.2.1 Назначение модели. Представление данных

1.2.2 Элементы модели

1.2.3 Диаграмма "сущность-связь"

1.2.4 Целостность данных

1.3 Иерархическая модель данных

1.3.1 Структура данных

1.3.2 Операции над данными

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

1.4 Сетевая модель данных

1.4.1 Структура данных

1.4.2 Операции над данными

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

1.5 Реляционная модель данных

1.5.1 Структура данных

1.5.2 Свойства отношений

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

1.5.4 Операции над данными (реляционная алгебра)

1.5.5 Ограничения реляционных баз данных

1.6 Постреляционные, объектно-ориентированные и объектно-реляционные СУБД

1.6.1 Постреляционные СУБД

1.6.2 Объектно-ориентированные СУБД

1.6.3 Объектно-реляционные СУБД

2. Описание требований веб-магазина по продаже фотоаппаратов

2.1 Предварительные замечания к проекту

2.1.1 Цели и рамки проекта

2.1.2 Деловой контекст

2.1.3 Участники проекта

2.1.4 Идеи в отношении решений

2.1.5 Обзор документа

2.2 Системные сервисы

2.2.1 Рамки системы

2.2.2 Функциональные требования

2.2.3 Требования к данным

2.3 Системные ограничения

2.3.1 Требования к интерфейсу

2.3.2 Требования к производительности

2.3.3 Требования к безопасности

2.3.4 Эксплуатационные требования

2.3.5 Политические и юридические требования

2.3.6 Другие ограничения

2.4 Проектные вопросы

2.4.1 Открытые вопросы

2.4.2 Предварительный план-график

2.4.3 Предварительный бюджет

2.5 Приложения

3. Спецификация требований для базы данных веб-магазина по продаже фотоаппаратов

Заключение

Список используемой литературы

Введение

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

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

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

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

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

2. Описание различных требований к информационной системе в рамках проекта веб-магазина по продаже фотоаппаратов.

3. Разработка и описание базы данных для веб-магазина по продаже фотоаппаратов.

4. Подведение итогов проделанной работы.

1. Модели данных, как инструментальные средства на этапах проектирования базы данных

1.1 Базы данных. Структура и типы данных

1.1.1 Зачем нужны базы данных

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

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

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

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

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

Основные функции СУБД:

· управление данными во внешней памяти (на дисках);

· управление данными в оперативной памяти;

· журнализация изменений и восстановление базы данных после сбоев;

· поддержание языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

· ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

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

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

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

1.1.2 Типы и структуры данных

Данные, хранящиеся в памяти ЭВМ представляют собой совокупность нулей и единиц (битов). Биты объединяются в последовательности: байты, слова и т.д. Каждому участку оперативной памяти, который может вместить один байт или слово, присваивается порядковый номер (адрес).

Любые данные могут быть отнесены к одному из двух типов: основному (простому), форма представления которого определяется архитектурой ЭВМ, или сложному, конструируемому пользователем для решения конкретных задач.

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

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

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

Такие структуры данных как массив или запись занимают в памяти ЭВМ постоянный объем, поэтому их называют статическими структурами. К статическим структурам относится также множество.

Рисунок 1.1 Классификация типов данных

Имеется ряд структур, которые могут изменять свою длину - так называемые динамические структуры. К ним относятся дерево, список, ссылка.

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

1.1.3 Обобщенные структуры или модели данных

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

Любая модель данных должна содержать три компоненты:

1. Структура данных - описывает точку зрения пользователя на представление данных.

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

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

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

· иерархическая,

· сетевая,

· реляционная.

1.2 Модель "сущность-связь"

1.2.1 Назначение модели. Представление данных

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

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

1.2.2 Элементы модели

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

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

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Наборы сущностей не обязательно должны быть непересекающимися.

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

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

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

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

Набор связей (relationship set) - это отношение между n (причем n не меньше 2) сущностями, каждая из которых относится к некоторому набору сущностей.

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

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

· один к одному (обозначается 1:1). Означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. Это представлен на следующем рисунке, где прямоугольники обозначают сущности, а ромб - связь. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией.

Рисунок 1.2 Связь один к одному

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

Рисунок 1.3 Кардинальность связей

· один ко многим (1:n). В данном случае сущности с одной ролью может соответствовать любое число сущностей с другой ролью. Графически степень связи n отображается "древообразной" линией, как на рисунке.

Рисунок 1.4 Связь один ко многим

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

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

Рисунок 1.5 Кардинальность связей степени n

· много к одному (n:1). Эта связь аналогична отображению 1:n.

Рисунок 1.6 Связь много к одному

Каждая сущность имеет обязательный класс принадлежности.

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

Рисунок 1.7 Связь многие ко многим

Если существование сущности x зависит от существования сущности y, то x называется зависимой сущностью (иногда сущность x называют "слабой", а "сущность" y - сильной). Таким образом, сущность является зависимой от другой сущности. Зависимую сущность обозначают двойным прямоугольником, а ее связь с сильной сущностью линией со стрелкой:

Рисунок 1.8 Зависимость сущности

Кардинальность связи для сильной сущности всегда будет (1,1). Класс принадлежности и степень связи для зависимой сущности могут быть любыми.

1.2.3 Диаграмма "сущность-связь"

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

Таблица 1. Элементы диаграммы "сущность-связь"

Обозначение	Значение
	Набор независимых сущностей
	Набор зависимых сущностей
	Атрибут
	Ключевой атрибут
	Набор связей

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

В процессе построения диаграммы можно выделить несколько очевидных этапов: иерархический сетевой реляционный база

1. Идентификация представляющих интерес сущностей и связей.

2. Идентификация семантической информации в наборах связей.

3. Определение кардинальности связей.

4. Определение атрибутов и наборов их значений (доменов).

5. Организация данных в виде отношений "сущность-связь".

1.2.4 Целостность данных

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

1. Ограничения на допустимые значения в наборе значений (домене). Домен можно трактовать как область определения атрибута, которая может быть задана либо непрерывным или дискретным интервалом, либо фиксированным списком значений.

2. Ограничения на разрешенные значения для каждого атрибута.

3. Ограничения на существующие значения в базе данных.

Но указанные ограничения невозможно представить на диаграмме "сущность-связь".



1.3 Иерархическая модель данных

1.3.1 Структура данных

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

Атрибут (элемент данных) - наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

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

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

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

При графическом изображении групповые отношения изображают дугами ориентированного графа, а типы записей - вершинами (диаграмма Бахмана).

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

Существуют следующие недостатки иерархических БД:

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

· иерархическая модель реализует отношение между исходной и дочерней записью по схеме 1:n, то есть одной родительской записи может соответствовать любое число дочерних.

1.3.2 Операции над данными

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

· Изменить значение данных предварительно извлеченной записи. Ключевые данные не должны подвергаться изменениям.

· Удалить некоторую запись и все подчиненные ей записи.

· Извлечь:

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

o извлечь следующую запись (следующая запись извлекается в порядке левостороннего обхода дерева)

В операции извлечь допускается задание условий выборки.

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

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

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

1.4 Сетевая модель данных

1.4.1 Структура данных

На разработку стандарта большое влияние оказал американский ученый Ч.Бахман. Основные принципы сетевой модели данных были разработаны в середине 60-х годов, эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL (1971 г.).

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

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

Каждый экземпляр группового отношения характеризуется следующими признаками:

· способ упорядочения подчиненных записей:

o произвольный,

o хронологический (очередь),

o обратный хронологический (стек),

o сортированный.

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

· режим включения подчиненных записей:

o автоматический - невозможно занести в БД запись без того, чтобы она была сразу же закреплена за неким владельцем;

o ручной - позволяет запомнить в БД подчиненную запись и не включать ее немедленно в экземпляр группового отношения. Эта операция позже инициируется пользователем.

· режим исключения. Принято выделять три класса членства подчиненных записей в групповых отношениях:

1. Фиксированное. Подчиненная запись жестко связана с записью владельцем и ее можно исключить из группового отношения только удалив. При удалении записи-владельца все подчиненные записи автоматически тоже удаляются.

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

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

1.4.2 Операции над данными

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

· Включить в групповое отношение - связать существующую подчиненную запись с записью-владельцем.

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

· Обновить - изменить значение элементов предварительно извлеченной записи.

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

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

· Исключить из группового отношения - разорвать связь между записью-владельцем и записью-членом.

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

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

1.5 Реляционная модель данных

Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.



1.5.1 Структура данных

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

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

Отношение: Отношением, определенным на множествах, называется подмножество декартова произведения. При этом:

· множества называются доменами отношения

· элементы декартова произведения называются кортежами

· число n определяет степень отношения (n=1 - унарное, n=2 - бинарное, ..., n-арное)

· количество кортежей называется мощностью отношения

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

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

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

Именованное множество пар "имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных.

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

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

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

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

1.5.2 Свойства отношений

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

2. Отсутствие упорядоченности кортежей.

3. Отсутствие упорядоченности атрибутов. Для ссылки на значение атрибута всегда используется имя атрибута.

4. Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться множества значений (отношения).

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

Целостность данных - это механизм поддержания соответствия базы данных предметной области. В реляционной модели данных определены два базовых требования обеспечения целостности:

· целостность ссылок

· целостность сущностей.

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

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

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

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

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

1. Связи между данными отношениями описываются в терминах функциональных зависимостей.

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

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

1.5.4 Операции над данными (реляционная алгебра)

1. Операции обработки кортежей. Эти операции связаны с изменением состава кортежей в каком-либо отношении.

· Добавить - необходимо задать имя отношения и ключ кортежа.

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

· Изменить - выполняется для названного отношения и может корректировать как один, так и несколько кортежей.

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

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

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

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

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

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

6. Декартово произведение. Входные отношения могут быть определены по разным схемам. Схема результирующего отношения включает все атрибуты исходных. Кроме того:

· степень результирующего отношения равна сумме степеней исходных отношений

· мощность результирующего отношения равна произведению мощностей исходных отношений.

7. Соединение. Данная операция имеет сходство с декартовым произведением. Однако, здесь добавлено условие, согласно которому вместо полного произведения всех строк в результирующее отношение включаются только строки, удовлетворяющие определённому соотношению между атрибутами соединения (А₁, A₂) соответствующих отношений.

8. Деление. Пусть отношение R, называемое делимым, содержит атрибуты (A₁, A₂, ..., A_n). Отношение S - делитель содержит подмножество атрибутов A: (A₁, A₂, ..., A_k) (k<n). Результирующее отношение C определено на атрибутах отношения R, которых нет в S, т.е. A_k+1, A_k+2, ..., A_n. Кортежи включаются в результирующее отношение C только в том случае, если его декартово произведение с отношением S содержится в делимом R.

1.5.5 Ограничения реляционных баз данных

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

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

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

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

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

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



1.6 Постреляционные, объектно-ориентированные и объектно-реляционные СУБД

1.6.1 Постреляционные СУБД

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

1.6.2 Объектно-ориентированные СУБД

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

В объектно-ориентированном программировании отсутствуют общие средства манипулирования данными, такие как реляционная алгебра или реляционное счисление. Работа с данными ведется с помощью одного из объектно-ориентированных языков программирования общего назначения, обычно это SmallTalk, C++ или Java.

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

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

ODMG (Object Data Management Group) - консорциум поставщиков ООБД и других заинтересованных организаций, созданный в 1991 г. Его задачей является разработка стандарта на хранение объектов в базах данных. В настоящее время опубликован вторая версия стандарта, которую так и называют ODMG 2.0.

Стандарт на хранение объектов ODMG 2.0 разработан на основе трех существующих стандартов: управление базами данных (SQL), объекты (стандарты OMG - Object Management Group) и стандарты на объектно-ориентированные языки программирования (C++, Smalltalk, Java).

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

1.6.3 Объектно-реляционные СУБД

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

В SQL-3 предполагается, что каждый объект имеет уникальный идентификатор - OID, именно он используется при создании ссылок на объекты.

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

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



2. Описание требований веб-магазина по продаже фотоаппаратов

2.1 Предварительные замечания к проекту

2.1.1 Цели и рамки проекта

Целью данного проекта является разработка веб-магазина по продаже фотоаппаратов. Сайт должен представлять магазин «ХХХ» в интернете, поддерживать его положительный и современный имидж, знакомить посетителей с продукцией и направлениями его деятельности, а также предоставлять информацию о способах приобретения продукции, расширяя границы бизнеса и рынка сбыта продукции.

2.1.2 Деловой контекст

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

2.1.3 Участники проекта

Заказчик - Иванов Иван Иванович (ivanov_ii@speed.ru)

Разработчик - Сергеев Сергей Сергеевич (ser_ser@ice.com)

2.1.4 Идеи в отношении решений

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



2.1.5 Обзор документа

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

2.2 Системные сервисы

2.2.1 Рамки системы

Рамки системы можно моделировать с помощью диаграммы контекста.

Рисунок 2.1 Контекстная диаграмма веб-магазина по продаже фотоаппаратов

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

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

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

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

2.2.2 Функциональные требования

Веб-магазин должен обеспечивать следующие функциональные возможности:

· Постоянная возможность получения актуальных значений товарных остатков в интернет магазине

· Автоматическое формирование платежных документов и прайс-листов

· Просмотр списка фотоаппаратов

· Поиск фотоаппарата по фирмам, характеристикам и т.д.

· Фильтрация товара по дополнительным характеристикам

· Просмотр описания фотоаппарата

· Добавление фотоаппарата в корзину

· Оформление заказа

· Автоматизация процесса оплаты товаров покупателем

· Формирование заказа на складе

· Доставка заказа

· Отслеживание заказов пользователей

· Закрытие заказа

· Возможность комментирования товаров

· Личный кабинет пользователя

· Интеграция и аутентификация с социальными сетями

2.2.3 Требования к данным

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

2.3 Системные ограничения

2.3.1 Требования к интерфейсу

Интерфейс веб-магазина должен иметь внешний вид, отвечающий следующим требованиям:

· Современный дизайн

· Единый стиль оформления

· Интуитивно понятное назначение элементов интерфейса

· Интерактивные подсказки для заполнения полей с данными

· Адаптивный дизайн веб-магазина под различные устройства

2.3.2 Требования к производительности

Особых требований к производительности ИС нет.

2.3.3 Требования к безопасности

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

2.3.4 Эксплуатационные требования

Веб-магазин должен функционировать в большинстве современных браузеров таких как: Mozilla Firefox, Google Chrome, Safari, Opera, Microsoft Edge, Internet Explorer и другие. Для поддержания и эксплуатации веб-магазина от персонала не должно требоваться специальных технических навыков, знания технологий или программных продуктов, за исключением общих навыков работы с персональным компьютером и браузером.

2.3.5 Политические и юридические требования

Нет.

2.3.6 Другие ограничения

Нет.

2.4 Проектные вопросы

2.4.1 Открытые вопросы

Нет.

2.4.2 Предварительный план-график

1.03.2016 - 5.03.2016 - Исследование рынка и разработка ТЗ

5.03.2016 - 12.03.2016 - Разработка дизайна веб-магазина

12.03.2016 - 20.03.2016 - Вёрстка шаблона и страниц веб-магазина

20.03.2016 - 04.04.2016 - Программирование серверной части

04.04.2016 - 09.04.2016 - Тестирование и отладка веб-магазина

09.04.2016 - 10.04.2016 - Ввод веб-магазина в эксплуатацию

2.4.3 Предварительный бюджет

Пятьдесят тысяч рублей.



2.5 Приложения

Глоссарий

· СУБД - система управления базами данных

· ТЗ - техническое задание

Деловые документы и формы

· Нет.

Ссылки

· Нет.



3. Спецификация требований для базы данных веб-магазина по продаже фотоаппаратов

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

База данных веб-магазина включает в себя три таблицы:

· Пользователи

· Фотоаппараты

· Заказы

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

Рисунок 3.1 Схема связи таблиц в БД

Таблица Пользователи имеет шесть полей:

· код - ключевое поле, тип данных: счетчик

· login - тип данных: короткий текст

· password - тип данных: короткий текст

· e-mail - тип данных: короткий текст

· адрес - тип данных: длинный текст

· заказ - тип данных: числовой

Рисунок 3.2 Таблица Пользователи

Все поля таблицы Пользователи являются обязательными, кроме поля заказа. Поле заказ связано с ключевым полем таблицы Заказы.

Таблица Заказы имеет четыре полей:

· код - ключевое поле, тип данных: счетчик

· товар - тип данных: числовой

· сумма - тип данных: денежный

· состояние заказа - тип данных: короткий текст

Рисунок 3.3 Таблица Заказы

Поле товар в таблице Заказы связано с ключевым полем таблицы Фотоаппараты.

Таблица Фотоаппараты имеет четыре поля:

· код - ключевое поле, тип данных: счетчик

· название - тип данных: короткий текст

· цена - тип данных: денежный

· описание - тип данных: длинный текст

Рисунок 3.4 Таблица Фотоаппараты



Заключение

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

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

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

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



Список используемой литературы

1. Системы управления базами данных и знаний. А. Наумов. 2015г.

2. Введение в реляционные базы данных. В. В. Кириллов, Г. Ю. Громов. БХВ-Петербург 2012 г.

3. Проектирование структур баз данных. Т. Тиори, Дж. Фрай. Мир 2010г.

4. Автоматизированные информационные системы, базы и банки данных. Н. А. Гайдамакин. Гелиос АРВ 2011г.

5. http://www.assist.ru/support_center/use/shops/requirement.htm (19.05.2016)

6. http://www.studmed.ru/docs/document1719?view=3 (15.05.2016)

7. http://studopedia.ru/2_10121_etapi-proektirovaniya-baz-dannih.html (20.05.2016)

8. http://www.belassist.by/toclients/connect/trebovanya/ (18.05.2016)

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

...