46911 (607991), страница 2

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

Текст из файла (страница 2)

1.6 Концептуальная модель

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

рис. 1.1

Графическое представление концептуальное модели наглядно поясняет предметную область.

1.7 Описание связей

1. Многие ко многим. Один поставщик поставляет много товара и одно

наименование товара может поставлять много поставщиков.

1. Один ко многим. Один поставщик может заключить много договор на

поставку товара с оптовой базой и в одном договоре может участвовать

только один поставщик

1. Один ко многим. С одним поставщиком может заключаться много счетов и

определенный счет может быть только у одного поставщика.

1. Многие ко многим. В одной накладной много товара и одно наименование

товара может быть во многих накладных.

1. Один ко многим. В одной накладной может быть несколько счетов.

2. Один ко многим. Заказчик создает много накладных.

3. Многие ко многим. В одном договоре много товара и одно наименование товара может встречаться в нескольких договорах.

4. Многие ко многим. Один заказчик заказывает партию товара и одно наименование товара может быть заказано многими заказчиками.

5. Один ко многим. С одним заказчиком может заключаться много счетов и только каждый счет соответствует одному заказчику.

6. Один ко многим. Счет создается на партию товара.

7. Один к одному. Договор может содержать только один счет.

1.8 Итоги построения концептуальной модели

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

2. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ

2.1 Выбор логической модели

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

• иерархическую

• сетевую

• реляционную

• объектно-ориентированную

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

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

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

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

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

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

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

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

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

• представление данных в виде двухмерных таблиц проще, чем виде списков;

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

• реляционная модель проста, обладает гибкой структурой, удобна для реализации на компьютере.

Выбор объектно-реляционной модели решил бы проблемы с реализацией связей, однако возникли бы неоправданные проблемы с созданием математического представления и выбором СУБД./4/ Принимая во внимание всё вышесказанное, делаем выбор – реляционная модель данных.

2.2 Основные понятия

Реляционная модель данных – это представление данных в виде совокупности двумерных таблиц./4/

Свойства двумерных таблиц:

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

2. все столбцы в таблице однородные, т.е. элементы столбца одной природы;

3. столбцам однозначно присвоены имена;

4. в таблице нет двух одинаковых строк;

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

Для математического описания реляционной модели нам понадобятся следующие понятия

Атомарные данные – это наименьшие единицы данных неразложимые с точки зрения модели.

Домен – это множество атомарных значений одного и того же типа.

Атрибут – это некоторое подмножество домена, имеющее уникальное имя.

Отношение на доменах D₁, D₂, ..D_n состоит из заголовка и тела.

R (A₁, A₂, ..A_n) D₁D₂D₃

Заголовок состоит из такого фиксированного множества атрибутов

А₁, A_2, ..A_n , что существует отношение между атрибутами и их доменами.

Тело состоит из меняющихся во времени множества кортежей.

Кортеж состоит из значений каждого атрибута по одному значению на атрибут./6/

Таблица в реляционной теории соответствует отношению.

Строке соответствует кортеж.

Столбцу – атрибут.

Введем понятие ключа отношения.

Пусть А – множество атрибутов отношения

А = A₁, A₂,..A_n и пусть k – это подмножество А

k A

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

1. в произвольный момент времени никакие два различных картежа не имеют одного и того же значения для k

2. ни один из атрибутов не может быть исключен из k без нарушения первого условия.

2.3 Проектирование реляционной модели

Существует два основных метода проектирования реляционной модели:

1. метод декомпозиции (используется при количестве ключевых атрибутов не более 20);

2. на основе концептуальной модели.

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

Алгоритмы перехода от концептуальной модели к реляционной

1. Реализация частичной связи для одной сущности (рис.2.1).

Рис 2.1

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

1. Реализация бинарной связи один-ко-многим (рис.2.2)

Рис.2.2

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

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

3. МАТЕМАТИЧЕСКОЕ ОПИСАНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ

3.1 Описание доменов

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

Домен – это множество атомарных значений одного и того же типа.

Введем следующие понятия:

Length(x) – функция, возвращающая значение длины x;

String(x) – функция определения длины строки х;

Dom(x) – домен атрибута х;

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

Текстовые атрибуты

К таким атрибутам можно отнести, например, атрибуты "Наименование заказчика" или "Адрес" и подобные им.

Dom (Отношение. Текстовый атрибут) = {x | String(x)}; где x – цепочка следующих друг за другом символов.

{String(x) = true, если Length(x) < С} or {String(x) = false, если Length(x) С},

где С-константа.

Её можно взять из таблицы атрибутов (см.табл.1.2). Приведём два примера.

2. Dom (Заказчики. Наименование заказчика) = {x | String(x)};

где x – цепочка следующих друг за другом символов.

{String(x) = true, если Length(x) < 20} or {String(x) = false, если Length(x) 20}

2. Dom (Поставщики. Адрес) = {x | String(x)}; где x – цепочка следующих друг за другом символов.

{String(x) = true, если Length(x) < 20} or {String(x) = false, если Length(x) 20}

Это правило распространяется на все текстовые атрибуты. Отличие заключается в ограничение на длину строки. Конкретную цифру получаем из таблицы атрибутов в столбце "Метод контроля" (см.табл.1.2).

Числовые атрибуты

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

Dom (Отношение. Числовой атрибут) = {с1..с2}, где с1 и с2 – соответственно начало и конец диапазона.

Например,

Dom (Заказчики. Код заказчика) = {0…10000}.

Диапазон значений {с1..с2} определяется для каждого атрибута описан в таблице атрибутов в столбце "Метод контроля" (см.табл.1.2).

Атрибуты Дата/Время

К этой категории относят атрибуты "Дата накладной", "Дата оформления счета", "Дата договора" и т.д.

Домены атрибутов Дата/Время записываются так:

Dom (Отношение. Атрибут Дата/Время) = {с1..с2},

где с1 и с2 – соответственно начало и конец диапазона.

Приведём примеры с атрибутами "Дата накладной", "Дата оформления счета"

Dom (Накладная. Дата накладной) = {x | 01.01.1996 x 31.12.2025}

Dom (Счет. Дата оформления счета) = {x | 01.01.1996 x 31.12.2025}

Диапазон значений {с1..с2} определяется для каждого атрибута описан в таблице атрибутов в столбце "Метод контроля" (см.табл.1.2).

Денежный атрибут

К этой категории относят атрибуты "Сумма", "Цена за единицу", "НДС".

Домены Денежных атрибутов записываются так:

Dom(Отношение. Денежный атрибут) = {

где С – константа

Приведем примеры с атрибутами "Сумма" и "Цена за единицу"

Dom (Накладная. Сумма) = {<0}

Dom (Договор. Цена за единицу) = {<0}

Значения для каждого атрибута взяты из Таблицы 1.2. столбца "Метод контроля"

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

Список файлов курсовой работы