Расписание

Преподаватель	День  недели	Номер  пары	Название дисциплины	Тип занятий	Группа
Петров В.И  Петров В.И  Петров В.И	Понед.  Вторник  Вторник	1  1  2	Теор.выч. проц.  Комп. графика  Комп. графика	Лекция   Лаб.раб  Лаб.раб	4906  4907  4906
Киров В.А.  Киров В.А.  Киров В.А.	Понед. Вторник Вторник	2  3  4	Теор.информ.  Пр-е на С++   Пр-е на С++	Лекция  Лаб.раб  Лаб.раб	4906  4907  4906
Минин А.А.  Минин А.А.  Минин А.А.	Понед. Среда Четверг	3  3  4	Защита инф.  Пр-е на VB   Пр-е на VB	Лекция  Лаб.раб  Лаб.раб	4944  4942  4922

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

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

R<ФИО, Номер зач.кн., Группа, Дисциплина, оценка>

Первичным ключом отношения является набор из двух атрибутов <Номер зачетной книжки, Дисциплина>. Однако если мы проанализируем функциональные зависимости, то увидим, что такие атрибуты, как «ФИО», «Группа» зависят только от части первичного ключа, а именно от атрибута «Номер зач. кн.». И в этом случае мы имеем неполные функциональные зависимости

Номер зач. кн.-> Группа

Номер зач. кн.->ФИО

И в этом случае для приведения ко 2-й нормальной форме надо разбить исходное отношение на 2 со следующими схемами:

R1<ФИО,Номер.зач.кн.,Группа>

R2<Номер зач.кн.,Дисциплина,Оценка>

3. Отношение находится в 3-й нормальной форме тогда и только тогда, когда оно находится во 2-й нормальной форме и не содержит транзитивных зависимостей.

Рассмотрим отношение, соответствующее описанию студента в некотором вузе.

R<ФИО,Номер.зач.кн.,Группа,Факультет,Специальность,Выпускающая кафедра>.

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

Номер.зач.кн. -> ФИО

Номер.зач.кн. -> Группа

Номер.зач.кн. -> Факультет

Номер.зач.кн. -> Специальность

Номер.зач.кн. -> Выпускающая кафедра

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

---

Группа -> Факультет

Группа -> Специальность

Группа -> Выпускающая кафедра

Выпускающая кафедра -> Факультет

И эти зависимости образуют транзитивные группы зависимостей. Чтобы избежать этого, мы можем предложить следующий набор отношений:

R1<Номер.зач.кн.,ФИО,Специальность,Группа>

R2<Группа,Выпускающая кафедра)>

R3(Выпускащая кафедра,Факультет)

4. Отношение находится в нормальной форме Бойса–Кодда, если оно находится в 3-й нормальной форме и каждый детерминант отношения является возможным ключом отношения.

Отношение, которое моделирует сдачу текущей сессии имеет следующую структуру:

<ФИО, Номер зач.кн., Идентификатор студента, Дисциплина, Дата, Оценка>

Если считать, что «Номер зач. кн.» и «Идентификатор студента» однозначно характеризуют его, то мы имеем два возможных ключа:

Идентификатор студента, Дисциплина

Номер зач.кн., Дисциплина

Кроме того, у нас существует 2 тривиальные функциональные зависимости:

Номер зач.кн.-> ФИО

Идентификатор-> ФИО

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

R1<Номер зач.кн.,ФИО>

R2<Идентификатор, Номер зач.кн.>

R3<Идентификатор, Дисциплина, Дата, Оценка>

Нормальные формы высших порядков связаны с наличием многозначных зависимостей. Многозначные зависимости, обозначаемые как A->>B, — это устойчивые соотношения между значениями атрибутов A и B, когда одному значению атрибута A соответствует некоторое устойчивое множество значений атрибута B. 

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

Имеем отношение «Планирование занятий»

Студент	Группа	Предмет	Номер лабораторной
Иванов	121	БД	ЛР-1
Иванов	121	БД	ЛР-2
Иванов	121	Сети	ЛР-1
Иванов	121	Сети	ЛР-2
Иванов	121	Сети	ЛР-2
Петров	122	БД	ЛР-1
Петров	122	БД	ЛР-2
Петров	122	ОС	ЛР-1
Петров	122	ОС	ЛР-2

 

В этом отношении 2 многозначных функциональных зависимости:

Группа ->> Предмет

Предмет->> Номер лабораторной работы.

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

---

Группы Студент Группа Иванов 121 Петров 122

Учебный план Группа Предмет 121 БД 121 Сети 122 БД 122 ОС

Практика Предмет Номер лабораторной БД ЛР-1 БД ЛР-2 Сети ЛР-1 Сети ЛР-2 Сети ЛР-3 ОС ЛР-1 ОС ЛР-2

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

Декомпозиция отношения R на проекции R1=R[X,Y] и R2=R[X,Z] будет декомпозицией без потерь тогда и только тогда, когда имеется многозначная зависимость X->>Y|Z.

5. Отношение R находится в 4-й нормальной форме тогда и только тогда, когда отношение находится в нормальной форме Бойса–Кодда и не содержит нетривиальных многозначных зависимостей.

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

R X Y Z 1 1 2 1 2 1 2 1 1 1 1 1

R[X,Y] X Y 1 1 1 2 2 1

R[X,Z] X Z 1 2

R[Y,Z] Y Z 1 2 2 1 1 1

 

Как легко заметить, отношение R не восстанавливается ни по одному из попарных соединений R₁JOIN R₂, R₁JOIN R₃ или R₂JOIN R₃. Действительно, соединение R₁JOIN R₂ имеет следующий вид.

 

X	Y	Z
1	1	2
1	1	1
1	2	2
1	2	1
2	1	1

 

Можно предположить, что отношение R удовлетворяет следующей зависимости соединения: *(XY,XZ,YZ).

6. Отношение R не находится в 5-й нормальной форме, если в отношении найдется нетривиальная зависимость соединения.

Отношение R находится в 5-й нормальной форме тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

В нашем случае набор из трех проекций и соответствует 5-й нормальной форме отношения R. 

---

5. Инфологическое моделирование БД, модель сущность связь и переход от инфологической модели к реляционной. [3. с. 121-129, 18 – тема 5].

Инфологическая модель иногда называется ER-моделью, что является сокращением названия Entity RelationShip, принятого для именования данного типа инфологической модели.

Сущность описывает класс однотипных объектов

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

Экземпляр сущности — объект из данного класса.

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

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

• «один к одному»(1:1)

• «один ко многим»(1:М)

• «многие ко многим»(М:М)

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

Рассмотрим на примере связи сущности «Студент» и сущности «Сессия». Каждый студент, сдавая сессию, получает определенные оценки по конкретным дисциплинам, при этом если считать, что одну и ту же дисциплину студент может пересдавать несколько раз, то первичным ключом экземпляра сущности «Сессия» будет набор атрибутов «Дисциплина, Дата сдачи экзамена». Однако студенты первого курса еще не сдавали в сессию ни одного экзамена, поэтому связь между сущностью «Студент» и «Сессия» 1:М и необязательная со стороны «Студент», но обязательная со стороны «Сессия», так как каждая оценка по конкретной дисциплине обязательно связана с некоторым студентом

Переход

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

---

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

Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREIGN KEY).

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

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

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

6. Распределенная обработка информации, модели «клиент-сервер» в системах баз данных.[3. с. 198-209, 18 – тема 6 ].

Вычислительная модель «клиент–сервер» исходно связана с парадигмой открытых систем, которая появилась в 90-х гг. и быстро эволюционировала. Сам термин «клиент–сервер» изначально применялся к архитектуре программного обеспечения, которое описывало распределение процесса выполнения по принципу взаимодействия двух программных процессов, один из которых в этой модели назывался клиентом, а другой — сервером. Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиентских процессов.

Основной принцип технологии «клиент–сервер» применительно к технологии баз данных заключается в разделении функций стандартного интерактивного приложения на 5 групп, имеющих различную природу:

• функции ввода и отображения данных — презентационная логика (Presentation Logic);

• прикладные функции, определяющие основные алгоритмы решения задач приложения — бизнес-логика, или логика собственно приложения (Business Logic);

• функции обработки данных внутри приложения (Database Logic);

• функции управления информационными ресурсами (Database Manager System);

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

---

Смотрите также файлы

• 7.docx

• 4.docx

• 6.docx

• 19.docx

• programmirovanie1.docx