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

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

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

Двумерные таблицы, которые содержат данные, должны удовлетворять следующим принципам (наиболее важным):

1) Каждая таблица содержит сведения о конкретном классе объектов.

2) Пересечения таблиц по информационным элементам отсутствуют (нет дублирования данных).

3) Каждая строка таблицы содержит сведения о конкретном объекте (в таблице нет двух одинаковых строк).

4) Все столбцы таблицы однородны (содержат данные одинаковой природы). Все столбцы таблицы однозначно поименованы.

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

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

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

Отсутствие дублирования по столбцам (пересечение таблиц по ИЭ) обеспечивается применением математических методов при формировании объектов.

Пример реляционной БД, - Студенческая канцелярия – её фрагмент представлен ниже:

В данной базе реализованы таблицы:

Студенты Дисциплины Успеваемость.

Студенты

Успеваемость

Дисциплины

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

Продемонстрировать с привлечением слушателей:

· Выбор ключевых элементов;

· Выбор связей;

· Правильный ввод данных.

Исходные условия для определения ключевых элементов вырабатываются на этапе исследования предметной области (ПО). Исходя их этих условий:

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

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

Для таблицы "Успеваемость" в качестве ключевого выбираем комбинацию полей "КодДисциплины" и "КодСтудента", поскольку:

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

· Точно также не выполняется свойство уникальности и в случае использования в качестве ключевого элемента только поля "КодСтудента", поскольку каждый из студентов имеет оценку по каждой из дисциплин;

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

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

Примеры СУБД.

Профессиональные: Oracle, Sybase, Informix, Ingress.

Персональные: Foxbase, FoxPro, Paradox, Access, Lotus.

Дата добавления: 2014-03-03; просмотров: 318; Нарушение авторских прав

Мы поможем в написании ваших работ!