Лекции по "Информатике"

 

Проектирование БД.

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

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

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

 Под сущностями понимаются понятия или объекты реального мира, информация о которых будут храниться в БД. Названиями сущностей являются, как правило, существительные, например, СТУДЕНТ, УСПЕВАЕМОСТЬ, ФАКУЛЬТЕТ, СПЕЦИАЛЬНОСТЬ. Сущность (иначе - объект) – это не конкретный объект, а именно некоторое понятие,  обобщающее  множество конкретных объектов, схожих по совокупности свойств и поведению. Обычно каждой сущности, в конечном счете, соответствует отдельная таблица БД. Экземпляры сущности – это конкретные объекты того типа, который символизирует собой сущность. Их называют также элементами данных или просто элементами. Экземпляру сущности соответствует одна строка (запись) в таблице БД, представляющей данную сущность. Свойства сущности называют атрибутами. Каждому свойству соответствует конкретный столбец (поле) таблицы БД. Например, атрибутами сущности СТУДЕНТ являются его Фамилия, Имя, Отчество, Номер зачетки и т.п. Каждый экземпляр сущности уникален в БД и однозначно идентифицируется по первичному ключу.

Пример. Разработать структуру базы данных в соответствии с приведенным ниже описанием предметной области «Университет».

Объекты  (тип сущности ) предметной области: ФАКУЛЬТЕТ, СПЕЦИАЛЬНОСТЬ, АБИТУРИЕНТ.

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

Список характеристик (свойств, атрибутов) объектов предметной области:

• код факультета, название факультета;
• код специальности, название  специальности;
• код абитуриента, ФИО абитуриента;
• дата проведения экзамена; название предмета; оценки каждого абитуриента по каждому предмету.

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

 

Первоначальным вариантом такой таблицы является таблица АБИТУРИЕНТЫ, представленная на рис.11. Эта таблица не является отношением, поскольку в ней имеются повторяющиеся группы данных для атрибутов КодАбитуриента, ФИО, ДатаПодачиДокументов. Повторяющиеся группы выделены в таблице серым цветом.

Для придания таким данным формы отношения необходимо реконструировать таблицу (нормализовать). Однако такое преобразование приводит к возникновению большого объема избыточных данных. Данные практически всех столбцов многократно повторяются (дублируются). Повторяются и некоторые наборы данных (КодФакультета – НазваниеФакультета, КодСпециальности – НазваниеСпециальности).

 

АБИТУРИЕНТЫ

Название Факультета	Код Аб.	ФИО	Дата Подачи Документов	Код Факуьтета	Код Специальности	Название Специальности
Факультет Информатики и Систем Управления	1	Петров П.П.	01.06.2006	ФИСУ	СА	Системный анализ
	2	Иванов И.И.	12.06.2006
	3	Сидоров  И.И.	12.06.2006
Факультет Гражданской Авиации	4	Петров П.П.	01.06.2006	ФГА	ЛА	Летательные аппараты
.        .       .

 

Рис.11 Ненормализованная таблица АБИТУРИЕНТЫ

АБИТУРИЕНТЫ

Код Аб.	ФИО	Дата Подачи Документов	Код Факуьтета	Название Факультета	Код Специальности	Название Специальности
1	Петров П.П.	01.06.2006	ФИСУ	Факультет Информатики и Систем Управления	СА	Системный анализ
2	Иванов И.И.	12.06.2006	ФИСУ	Факультет Информатики и Систем Управления	СА	Системный анализ
3	Сидоров  И.И.	12.06.2006	ФИСУ	Факультет Информатики и Систем Управления	СА	Системный анализ
4	Петров С.П.	01.06.2006	ФГА	Факультет Гражданской Авиации	ЛА	Летательные аппараты
				.        .       .

Рис.12 Нормализованная таблица АБИТУРИЕНТЫ

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

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

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

1.Например, при изменении названия факультета в таблице АБИТУРИЕНТЫ потребуется корректировка записей обо всех абитуриентах, поступающих на этот факультет.

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

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

Аномалии добавления - когда информацию в таблицу нельзя поместить до тех пор, пока она неполная, либо вставка новой записи требует дополнительного просмотра таблицы. Примером может служить невозможность хранить в таблице АБИТУРИЕНТЫ на рис.2 данные о факультетах и специальностях, пока ни один абитуриент не подал документы на данную специальность.

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

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

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

Виды связи между таблицами

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

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

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

Выделяют 3 типа связи между таблицами:

1) отношение «один-ко-многим» ( 1:М ):

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

 

«Наименование группы» (главная, ссылочная)

Код группы (первичный ключ)     Код специальности    Куратор        Год формирования группы     

     БУ-13                                                  080810                 Иванов           2007

     МО              091020         Федоров

     .              .               .          .

     .              .                               .                       .

 

 

«Список группы»   (подчиненная, ссылающаяся таблица)

Код группы (внешний ключ)       Номер зачетной книжки         Фамилия

   БУ-13         12455          Петров

   БУ-13                      12356                   Сидоров

   БУ-13         12357                   Иванов

    .    .         .

    .     .        .

 

    МО-11                      251324                  Анцифиров

Т.е. описания групп и  состав групп. Все списки студенов, т.е. более одного студента

 

Отношению «один-ко-многим» соответствует парное ему отношение «многие-к-одному» ( М:1 ). Фактически, это один и тот же вид связи, поскольку эти два вида связи различаются только направлением.

2) отношение «один-к-одному» ( 1:1 ):

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

 

3) отношение «многие-ко-многим» ( М:М ):

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