Методология проектирования баз данных в процессе обучения

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

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

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

«База данных» - это дисциплина, которая дается студентам и включает в себя лекции, лабораторный практикум и курсовую работу. Дисциплина основывается на таких курсах как «Информатика», «Математика», «Программирование» и сама, в свою очередь, является базой для изучения дисциплин по проектированию информационных систем и дипломного проектирования.

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

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

На основе этапа системного анализа осуществляется переход ко второму этапу – инфологической модели информационной системы. Под инфологической моделью понимается некоторое формализованное описание структуры базы данных, и сделать это можно различными способами. В нашем случае для описания инфологической модели используется, так называемые, ER модели (ENTITY RELATIONSHIP), иначе модели «Сущность – связь». В основе ER модели лежат три понятия: сущность, атрибут и бинарные ассоциативные связи между сущностями. ER модель информационной системы может быть представлена в виде рисунка, где изображаются основные сущности с их атрибутами, а также взаимосвязи между сущностями. Информацию о модели оформляют составлением спецификаций по сущностям, атрибутам и отношениям с использованием графических диаграмм. На рис.1 приведен пример инфологической модели.

Рис.1. Пример инфологической модели где задано графическое обозначение

- сущность

- атрибут

• -    связь

• -    связь один к одному

• -    связь один ко многим

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

На следующем этапе нужно выбрать систему управления базами данных (СУБД). Здесь перечисляются современные СУБД, их характеристики и способы организации данных в виде дерева, сети или взаимосвязанных таблиц, т.е. реляционные СУБД. Поскольку большинство современных СУБД являются реляционными и организация данных в виде таблиц наиболее удобна для восприятия и работы, студентам предлагается выбирать именно их. Кроме того от сетевой или иерархической организации данных легко перейти к реляционным моделям. Поэтому далее уже более детально изучаются именно реляционные базы данных (РБД), переход от ER модели к реляционной, правила перехода, математика, на которой строится работа с РБД, основная терминология РБД. Согласно этой терминологии, например, таблица в РБД называется отношением. Отсюда и название «Реляционные БД»

На четвертом этапе изучаются вопросы логического проектирования, а именно, даталогического проектирования РБД, базирующегося на теории нормализации, которую разработал американский математик D.Kodd. Согласно этой теории существует только один набор таблиц, с помощью которых могут быть представлены все данные, и при этом операции добавления, изменения и выбора данных будут производиться наиболее эффективно. Таблицы согласно D.Kodd должны быть нормализованы. Соответственно определены первая нормальная форма (1НФ), вторая (2НФ), третья (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая(4НФ) и пятая нормальная форма (5НФ). Нормализация – это переход от более низких форм (1НФ) к более высоким формам. И хотя на практике ограничиваются 3НФ, наши студенты, как будущие специалисты по разработке информационных систем, изучают все нормальные формы.

Пусть имеется отношение Сотрудники

Сотрудники(Таб№, ФИО, Оклад, Комната, Телефон, Дети)

Данное отношение представлено в таблице 1.

Таблица 1: Сотрудники

Таб№	ФИО	Оклад	Комната	Телефон	Дети
					Имя_ребенка	Возраст_ ребенка
211	Иванов И.И.	5000	12	616	Саша Женя Вася	10 7 3
358	Темин Т.Т.	7000	12	616	Вова	5
360	Котов К.К.	10000	5	306	Таня Саша	8 6

Атрибуты Таб№, ФИО, Оклад, Комната, Телефон являются простыми, а вот атрибут Дети – это сложный атрибут. Такая таблица является ненормализованной и обладает существенными недостатками, связанными со сложностью модификации данных и неоднозначностью запросов. Поэтому в процессе проектирования базы данных перед студентами ставится задача нормализации таблицы, т.е. приведения к первой нормальной форме, затем ко второй и третей нормальной формам (3НФ). В результате нормализации и приведения к 3НФ получим следующие отношения:

Дети( Таб№, Имя_ребенка , Возраст_ребенка)

Сотрудник( Таб№ , ФИО, Оклад, Комната)

Комната( №комнаты, Телефон)

Данные отношения являются полностью нормализованными.

Языки запросов и программирования

Для работы с базами данных используются в основном два языка: SQL и QBE. Язык QBE – это табличный язык запросов, который используется в СУБД

ACCESS, и студенты достаточно подробно знакомятся с ним на лабораторных занятиях[2]. На лекциях же мы ограничиваемся несколькими примерами, чтобы дать некое представление об этом языке. Более подробно изучается структурированный язык запросов SQL, который является стандартом языков запросов и встроен практически во все СУБД, в частности и в ACCESS. На большом количестве примеров демонстрируются все возможности языка, разбираются алгоритмы работы запросов с таблицами базы данных. Поскольку SQL использует операции над таблицами: объединение, пересечение, декартово произведение, горизонтальное и вертикальное подмножества и т.д., то достаточно подробно разбираются эти операции.

В языке SQL предусмотрено четыре оператора манипулирования данными: SELECT, UPDATE, DELETE, и INSERT. На различных примерах происходит изучение возможностей применения основных операций языка SQL: выборка, обновление, вставка и удаление данных. Многие СУБД имеют встроенный внутренний язык программирования. Так, например, весьма популярным и широко применяемым является язык программирования Visual FoxPro. Данный язык имеет широкий спектр применения: возможность работы с таблицами, массивами, файлами, создание отчетов, построение интерфейса, использование языка запросов SQL, использование элементов объектно-ориентированного программирования.

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

Весь материал, изучаемый на лекциях, закрепляется затем на лабораторных работах и при выполнении курсовой работы. Лабораторный практикум состоит из 8ми работ [2]. Первые три – это СУБД FoxPro, затем язык запросов SQL, три работы – СУБД ACCESS и последняя – это система программирования Delphi, связывание ее с ACCESS и соответственно работа с базами данных.

Для курса «Базы данных» разработан учебно-методический комплекс, который содержит все необходимые методические материалы для изучения дисциплины. Кроме того, для студентов заочников разработано и издано методическое пособие, где в сжатой форме содержится вся необходимая информация, а именно: теоретический материал, лабораторный практикум и методическое руководства для выполнения курсовой работы.

Методология проектирования распределенных баз данных

На 4-ом курсе студенты направления «Информатика и вычислительная техника» изучают дисциплину «Распределенные базы данных» опираясь на использование СУБД MS SQL Server или СУБД Oracle [3]. На лекциях они получают теоретические знания, связанные с построением распределенных баз данных с различной архитектурой. Дается классификация систем по способам распределенной обработки данных. Рассматриваются различные типы систем, различающихся по характеру распределения данных: системы с централизованными данными, иерархические системы, системы с разделенными данными, реплицированные системы и гетерогенные. Приводится архитектура моделей удаленного доступа, например, модель файлового сервера, модель сервера баз данных и др. При распределенной обработке данных к одним и тем же данным возможен доступ множества клиентов. Возникает проблема параллельных запросов. При параллельных запросах к одним и тем же данным могут возникнуть следующие проблемы: потеря результатов обновления, появление «грязных» данных, несовместимый анализ и др. Для решения этих проблем используются блокировки различного уровня: на уровне записей, таблиц, баз данных. Непосредственное взаимодействие с базой данных производится на уровне транзакций. Транзакции переводят базу данных из одного согласованного состояние в другое согласованное. Транзакция является важным элементом надежной работы базы данных.

Безопасность баз данных

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

Курсовое проектирование базы данных

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

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

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

Рис.2. Инфологическая модель предметной области «Библиотека»

Основными сущностями являются: Книги, Читатели и Экземпляр.

Каждая сущность включает некоторое множество атрибутов.

Книга (Шифр книги, Название, Авторы, Издательство, Город издания, Год издания, Количество страниц, Номер области знаний, Название области знаний, Количество экземпляров, Цена)

Читатель (№читат.билета, Фамилия, Дата рождения, Телефон(рабочий), Телефон (домашний), Место работы, Домашний адрес)

Экземляр (Инвентарный номер, Место размещения, Вкладыш)

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

Нормализация отношений

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

Рассмотрим отношение «Книги». Каждая книга может относиться ко многим областям знаний, т.е. атрибуты номер области знаний и название области знаний – сложные, а это значит, что нарушена 1-ая нормальная форма. Чтобы привести к 1-ой нормальной форме добавим к ключу еще один атрибут – номер области знаний (рис.3)

Отношения «Читатель» и «Экземпляр» находятся в 1-ой нормальной форме, так как не имеют сложных атрибутов.

Поскольку отношения «Читатель» и «Экземпляр» имеют простые ключи, они уже во 2-ой нормальной форме. В отношении «Книги» 2-ая нормальная форма нарушена, т.к. есть неключевые атрибуты, зависящие только от части ключа, а не от всего составного ключа. Приведем это отношение ко 2-ой форме, разделив отношение на три отношения по зависимости от ключа или части ключа. Результат представлен на рис.3.

Назовем новые отношения: «Книги», «Области знаний», «Принадлежность книги к области знаний».

В результате мы получили 5 отношений: «Книги», «Экземпляр»,

«Области знаний», «Принадлежность книги к области знаний», «Читатель».

Отношение «Книги»

шифр СТИГИ ------- номер области знаний название области знаний название ^____________ фамилии автор ов ◄—

издательство N---------------------------------------- гор од издания 4------------------------------- год издания <-------------------------------- количе ство стр аниц в книге         n цена стиги -N--------------------- количество экземпляров в библиотеке

Рис.3. Функциональные зависимости атрибутов

Логическая модель базы данных

После выбора СУБД и этапов нормализации должна быть получена логическая модель (рис.4).

В эту модель добавили еще одно отношение «Статистика» , которая позволяет учитывать, как часто запрашивается читателем та или иная книга.

Рис.4. Логическая модель базы данных «Библиотека»

Далее выполним физическое проектирование в среде СУБД Microsoft Access 2000. Поименуем таблицы и атрибуты, определим типы данных и размерность атрибутов.

В таблицах выберем первичные ключи и индексированные поля ( представить структуру таблиц, например фрагмент описания структуры таблицы Книги представлен в таблице 2 ).

Таблица 2. Структура таблицы «Книга» РБД «Библиотека»

Название таблицы	Имя поля	Тип данных	Размер поля	Первичный ключ / вторичный ключ / индексированное поле
Книга	Шифр книги	Текстовый	15	Первичный ключ
	Название	Текстовый	50
	Авторы	Текстовый	50
	Издательство	Текстовый	20
	Город издан.	Текстовый	20
	Год издания	Текстовый	4
	Кол_страниц	Числовой

	Количество экз. в библ.	Числовой
	Цена	Денежный

Связи между таблицами в базе данных «Библиотека» представлены на рис.5, полученные средствами Microsoft Access.

Рис.5. Связи между таблицами в базе данных

На рис.6 представлен интерфейс для работы с базой данных «Библиотека»

Рис.6. Интерфейс базы данных

Запросы на выборку данных

На рис.7 и 8 приведены примеры, осуществляемые в системе Access с помощью табличного языка QBE. На рис.7 запрос для выявления задолжников, а на рис.8. запрос для получения списка книг по программированию.

Рис.7. Запрос для выявления «злостных» задолжников

Рис.8. Запроса для получения списка книг по программированию.

Заключение

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

• -    провести глубокий анализ предметной области;

• -    разработать инфологическую и логическую модель предметной области;

• -    произвести выбор системы управления базой данных;

• -    разработать эффективную логическую структуру базы данных;

• -    осуществить все этапы нормализации таблиц и их взаимосвязей;

• -    используя языки запросов и программирования создать удобный интерфейс для работы с базой данных;

• -    разработать формы выдаваемых отчетов.

Получив знания по таким СУБД, как Access, Visual FoxPro, MS SQL Server, Oracle, MySQL студенты легко адаптируются в промышленности, даже в случае если им приходится сталкиваться с новыми системами.