- объект

- свойство

Связи между объектом и его свойствами

личность

5 видов связи:

* Эти свойства позволяют построить от 1 до N таблиц.

Связи между объектами или степени связи

1) Один к одному (один элемент класса соответствует одному элементу другого класса)

2) Один ко многим (один элемент одного объекта соответствует многим элементам др объекта)

3) Многие к одному

4) Многие ко многим

* Элемент – запись, строка

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

Обязательная связь (·)

Личность

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

(Многие личности владеют одним языком)

Пример 2. Каждая личность обязана владеть одним языком не более

?? к одному

Пример 3. Каждая личность обязана владеть одним или более чем одним иностранным языком

Многие ко многим

Разновидность объектов

Объекты различаются по своей структуре и бывают:

1) Простой объект – это объект единый и неделимый

2) Сложные объекты

1. Составные объекты – он отображает связь от целого к части (группа и студенты)

Один ко многим

Многие ко многим

2. Обобщённый объект он отображает наличие связи род-вид

- Видовое свойство

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

3. Агрегированные объекты . Такой объект соответствует какому-то процессу над другими объектами. Он может иметь свойства простых объектов, на базе которых он строится, плюс набор своих свойств (свои свойства могут отсутствовать)

Он обозначается

Ключ – это один или боле атрибутов, которые однозначно определяют единицу объекта (строку таблицы)

Ключи бывают:

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

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

Даталогическое проектирование.

Даталогическое проектирование строится на конкретных технических средствах и ориентируется на конкретную СУБД. Существует 3 типа БД:

1. Реляционные БД

2. Сетевая\сетевые БД

3. Иерархическая БД

Реляционная БД – наиболее простой способ хранения информации, реализован на всех СУБД, работающих на современной технике типа IBM PC и им подобных. Принцип построения реляционной модели - это построение таблиц или их ещё называют реляционными отношениями.

имяотношения (атр1, атр2, … атр n)

ключ

Требования к реляционным отношениям:

1. Таблица должна состоять из строк и столбцов простой структуры:

Атр1	Атр2	Атр3	Атр4
1
2

Сложная структура (так не может быть):

Атр1	Атр2
1
2
Или
5

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

3. Порядок столбцов строго установлен и конечен

4. Количество строк – меняющаяся величина

5. Каждая строка представляет собой набор значений

6. Строки могут обрабатываться в любом порядке

7. Строки таблицы должны отличаться хотя бы одним значением

8. Каждая таблица должна иметь ключевое поле

Проектирование реляционной базы

Существует 2 способа проектирования базы или построения реляционных отношений:

1 способ: На основе анализа инфологического моделирования и использования свойств объектов строится реляционное отношение.

2 способ: Построение нормальных форм посредством нормализации.

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

Правила построения

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

Свойство 1 (Идентификатор объекта)

Свойство 1

Свойство N

RO1 (ИО, Св-во1, Св-во2 … Св-во N) – единичное(?) реляционное отношение

Единичное отношение

2. Если у объекта есть множественное свойство, то каждому такому свойству строится отдельное реляционное отношение. Ключом отношения будет идентификатор объекта.

Свойство 1 (Идентификатор объекта)

Свойство 2

Св-во N

Св-во N+1

RO21 (ИО, Св-во1, Св-во2 …) RO22 (ИО, Св-во N+1) RO23 (ИО, Св-во N)

множественное свойство

3) Если между объектом и его свойством есть условная связь, то существует 2 варианта хранения такой информации:

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

Свойство 1 (Идентификатор объекта)

Свойство 2

Св-во 3

У

Св-во 4

RO3 (ИО, Св-во1, Св-во2 … Св-во 4)

• Когда условная связь присуща малому количеству экземпляров (строка, запись) объекта (телефон рабочий у студента):

Рис тот же

RO31 (ИО, Св-во1, Св-во2, Св-во 3)

RO32 (ИО, Св-во 4)

4. Динамические свойства в предметных областях типа склады, магазины эффективно хранить в отдельном реляционном отношении (аналог 32).

5. Один к одному (1 : 1) :

• связь между объектами обязательная:

Св-во 1 (ИО5_1) PK ИО 5_2 (PK)

Св-во 2_5_1 Св-во 2_5_2

Св-во 3_5_2

RO5_1 (ИО 5_1, Св-во2_5_1, ИО 5_2, Св-во2_5_2, Св-во 3)

• связь 1 к 1 и обязательная только у одного из объектов (у второго объекта):

RO 5_1 (ИО 5_1, Св-во2_5_1)

RO 5_2 (ИО 5_2, Св-во2_5_2, Св-во 3, ИО 5_1)

• связь необязательная:

RO 5_1 (ИО 5_1, Св-во2_5_1)

RO 5_2 (ИО 5_2, Св-во2_5_2, Св-во 3, ИО 5_1)

RO 5_3 (ИО 5_1, ИО 5_2)

По предметной области принимаются бизнес-правила и уточняются связи и обязательность связей.

6. Связь 1 ко многим существуют 2 правила:

• когда связь между одним объектом обязательна, а между вторым нет.

RO 6_1 (ИО 6_1, Св-во2_6_1)

RO 6_2 (ИО 6_2, Св-во2_6_2, Св-во 3, ИО 6_1)

• связь 1 ко многим и необязательная

RO 6_1 (ИО 6_1, Св-во2_6_1)

RO 6_2 (ИО 6_2, Св-во2_6_2, Св-во 3)

RO 6_3 (ИО 6_1, ИО 6_2)

7. Связь многие ко многим (всегда необязателен)

RO 7_1 (ИО 7_1, Св-во2_7_1)

RO 7_2 (ИО 7_2, Св-во2_7_2, Св-во 3)

RO 7_3 (ИО 7_1, ИО 7_2)

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

RО 8_3

RО 8_2

RО 8_1

ИО8_2

ИО8_1

Действие RO8_5

Св-во N

Св-во N+1

RO 8_4 (ИО 8_1, ИО 8_2, ИО 8_3 Св-во1, Св-во2)

В одной предметной области может быть n кол-во агрегированных объектов и агрегированные объекты между собой не взаимодействуют. Тогда:

RO 8_4 (ИО 8_1, ИО 8_2, ИО 8_3 Св-во1, Св-во2)

RO 8_5 (ИО 8_1, ИО 8_2, ИО 8_3 Св-воN, Св-воN+1)

9. Обобщённый объект

9.1

RО 9

Св-во 1

Св-во 2

Св-во 3

Св-во 4

Св-во 5

RO 9_1 (ИО9, Св-во1, св-во 2, св-во 3)

RO 9_2 (ИО9, Св-во1, св-во 4, св-во 5)

9.2 (лучше с точки зрения хранения и отсутствия избыточности)

RO 9_3 (ИО9, Св-во 1)

RO 9_4 (ИО9, Св-во 2, Св-во 3)

RO 9_5 (ИО9, Св-во 4, Св-во 5)

9.3

RO 9_6 (ИО9, Св-во 1, Св-во 2… Св-во 5)

При проектировании ER-моделей используются СASE-технологии (CASE-системы), которые позволяют спроектировать предметную область, построить таблицы Desing/IDEF, CASE ORACLE (Designer), WORKBENCH, BPwin и ERwin.

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

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

RO 1 (Св-во 1, Св-во2, Св-во 3, …)

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

Первая нормальная форма

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

RO 1 (Св-во 1, Св-во2, Св-во 3, …)

З,

Д,

В

RO 3

RO 4

RO2 (Код покуп, Наим пок, Адрес, Телефон)

RO3 (Код продав, Наим продавца, Юр адрес)

RO4 (Код товара, Наименов товара, Стоимость ед товара, Ед измерения, Характ товара, Кол-во товара)

RO5 (Скидка на товар)

RO6 (Способ доставки, Стоимость доставки)

RO7 (Физ нахожд товара)

RO8 (Код склада, Адрес склада, Телефон склада)

R09 (Код магазина, Адрес магазина, Телефон магазина)

RO10 (Код компании, Наименование компании, телефон)

2 Нормальная форма

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

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

RO 1( , Св-во 3, Св-во 4, Св-во 5 )

RO2 (Код покуп, Наим пок, Адрес, Телефон,…)

RO3 (Код продав, Наим продавца, Юр адрес)

RO4-1 (Код товара, Наименов товара, Характ товара )

RO4-2 (Код товара, Код продав, Ед измерения, Стоимость за ед товара , Кол-во товара )

RO5-1 (Код товара, Код продав, Скидка на товар)

RO5-2 (Код товара, Код магазина, Скидка на товар)

RO6-1(Код доставки, Способ доставки, Расстояние, Время доставки)

RO6 (Код компании, Стоимость доставки)

RO10 (Код компании, Наименование компании, телефон)

RO8 (Код склада, Адрес склада, Телефон склада)

R09 (Код магазина, Адрес магазина, Телефон магазина)

RO7-1 (Код товара, Код склада, Ед измерения, Кол-во товара)

RO7-2 (Код товара, Код магазина, Ед измерения, Кол-во товара)

…

3 Нормальная форма

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

RO10-1 (Код компании/дост, Наименование компании)

RO10-2 (Код компании/дост, телефон )

RO2 (Код покуп, Наим пок, Адрес, Телефон)

RO3 (Код продав, Наим продавца, Юр адрес)

RO4-1 (Код товара, Наименов товара, Характ товара )

RO4-2-1 (Код товара, Код продав, Ед измерения, Стоимость за ед товара)

RO4-2-2 (Код товара, Код продав, Код магазина, Кол-во товара )

RO4-2-3 (Код товара, Код продав, Код склада, Кол-во товара )

RO5-1 (Код товара, Код продав, Скидка на товар)

RO5-2 (Код товара, Код магазина, Скидка на товар)

RO8 (Код склада, Адрес склада, Телефон склада)

R09 (Код магазина, Адрес магазина, Телефон магазина)

RO7-1 (Код товара, Код склада, Ед измерения, Кол-во товара)

RO7-2 (Код товара, Код магазина, Ед измерения, Кол-во товара)

RO6-1-1(Код доставки, Способ доставки)

RO6-1-2(Код расстояния, Расстояние)

RO6 (Код компании, Код доставки, Код расстояния, Время доставки, Стоимость доставки)

4 Нормальная форма

Отношение находится в 4НФ, если оно находиться во 3НФ и между реквизитами отношений нет многозначной зависимости.

RO (С1,С2,С3) RO-1 (С1,С2) и RO-2(С1,С3)

1 2 3 1 2 1 2

1 3 2 1 3 1 3

1 2 2

1 3 3

RO10-1 (Код компании/дост, Наименование компании)

RO10-2 (Код компании/дост, телефон)

R09-1 (Код магазина, Наименование магазина)

R09-2 (Код магазина, Телефон магазина)

R09-3 (Код магазина, Адрес магазина)

RO2 (Код покуп, Наим пок, Адрес, Телефон)

RO3 (Код продав, Наим продавца, Юр адрес)

RO4-1 (Код товара, Наименов товара, Характ товара)

RO4-2-1 (Код товара, Код продав, Ед измерения, Стоимость за ед товара)

RO4-2-2 (Код товара, Код продав, Кол-во товара)

RO4-2-3 (Код товара, Код продав, Кол-во товара)

RO5-1 (Код товара, Код продав, Скидка на товар)

RO5-2 (Код товара, Код магазина, Скидка на товар)

RO8 (Код склада, Адрес склада, Телефон склада)

RO7-1 (Код товара, Код склада, Ед измерения, Кол-во товара)

RO7-2 (Код товара, Код магазина, Ед измерения, Кол-во товара)

Покупатель

Пример построения реляционных отношений на основе инфологического моделирования.

Объекты:

R1 (Код покупателя, Наим покупателя, Адрес, Телефон)

R2 (Код продавца, Наим продавца, Юр адрес)

Скидка

R3 (Код товара, Наим. Товара, Хар-ка товара)

R3-1 (Код товара, Ед. измерения, Стоимость)

* Рассуждаем что Стоимость зависит от Ед. измерения => одно реляционное отношение

R4 (Код магазина, Наим. магазина)

R4-1 (Код магазина, Адрес, Телефон)

R5 (Код склада, Адрес, Телефон)

R6 (Код компании, Наим. компании)

R6-1 (Код компании, Телефон)

R7-3-5 (Код товара, Код склада, Кол-во товара)

1:M

Склад

необязат

R8-2-3 (Код товара, Код продавца, Ед измерения, Кол-во товара)

1:M

Товар

… и т.п.

Магазин

Доставка

Кол-во товара

Ед измерения

и т.д. (напр, Дата)

R9 (Код покупателя, Код продавца, Код товара, Код магазина, Код склада, Код компании по доставке, Кол-во товара, Ед измерения)

Продавец\

поставщик

R8-1-3-2 (Код продавца, Код покупателя, Код товара, Скидка)

Расчёт объёма памяти реляционной бд.

1 шаг. Рассчитать длину строки

2 шаг. Расчет объема данных

3 шаг. Длина индекса

4 шаг. Объём индекса

* 1-4 для каждой таблицы повторяется M раз (M-кол-во таблиц)

5 шаг. Объём БД

1. 0 – 255 занимает 1 байт,

2. приблизительно -32000 - +32000 занимает 2 байта,

3. приблизительно -2 000 000 000 - +2 000 000 000 занимает 4 байта,

4. <-2 000 000 000 и >+2 000 000 000 занимает 8 байт.

Типы бд. Сетевая модель данных

см. ранее «Даталогическое проектирование»

Сетевая БД реализует тип связи многие ко многим и устанавливает 2 типа взаимосвязей:

1) между отдельными полями внутри одного файла.

2) между различными файлами.

В сетевой модели данных файлы бывают:

1. Основные (основные типы данных) - это файлы, которые строятся из реляционных отношений, на которые ссылаются другие файлы (или строятся на основе этих файлов)

2. Зависимые (зависимые типы данных) - это реляционные отношения, содержащие данные пересечений.

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

Пример.

R1 (А, B, C ... K)

R2 (L, M, ... P)

R3 (R, S, ... W)

А, B, C ... K - атрибуты

На базе первых трёх строим четвёртое реляционное отношение, которое будет иметь данные пересечения.

R4 (А, B, ..M,... R ... W, X, Y, Z) - добавились 3 атрибута, не встретившихся в 1, 2, 3.

R1, R2, R3 - файл с основными типами данных.

R4 - файл с зависимым типом данных.

Требования к сетевой модели

• Должны существовать 2 типа данных - основные и зависимые.

• Между файлами должна существовать взаимосвязь и она охватывает 2 типа данных. (Всегда взаимосвязь между основным и зависимым).

• Один и тот же тип данных не может быть одновременно основным и зависимым.

• Основный тип данных (файл) может не иметь связей с зависимым типом.

• А зависимый тип данных обязательно должен иметь связь с основным типом данных. Взаимосвязь между основным и зависимым файлам осуществляется по адресным указателям.

Пример (из примера про реляционные отношения)

Покупатель (Код покупателя (PK), Наименование, Адрес ....)

Товар (Код товара (PK), Название, Стоимость ....)

Поставщик\продавец (Код поставщика (PK), Наименование ....)

....

Доставка (Код доставки (FK), Код покупателя (FK), Код поставщика (FK), Код товара (FK), Код склада (FK), Дата, Кол-во товара, ....)

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

Основной тип данных (Покупатель, Товар, Поставщик), зависимый тип данных(Доставка)

Код доставки (Код доставки (PK))

Код склада (Код склада(PK))

Основные дополнительные типы данных (Код доставки, Код склада)

От первичного ключа может быть N кол-во связей к зависимым файлам, тогда:

Основной файл:

Объём бд сетевой модели

1 шаг. Считаем длину основных файлов

2 шаг . Объем основных файлов

3 шаг. Считаем длину зависимых файлов

4 шаг. Объем зависимых файлов

5 шаг. Объем общий

Типы бд. Иерархическая модель

Например, СУБД Седан

Реализует связь 1 ко многим и представляет собой упорядоченное дерево. Дерево состоит из корня, дуг и узлов. В дереве корень всегда один и это корневой сегмент.

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

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

A

M

B

N

1

∞

G

A – корневой, исходящий сегмент.

B, C, L … - Все остальные - порожденные

C, D, L, M – Исходящие сегменты

Каждая дуга определяет связь один ко многим.

Правила построения иерархической модели:

1. Выбирается отношение с наибольшим количеством ключевых полей.

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

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

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

5. Поля данных (не ключевые поля) в дереве из реляционного отношения п.1 располагаются на последнем уровне дерева.

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

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

Пример:

Код покупателя

∞

Хар-ка товара