Проектирование баз данных

Размещено на http://www.allbest.ru/

ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

МЕТОДИЧЕСКИЕ УКАЗАНИЯ К КУРСОВОМУ ПРОЕКТУ

ПО ДИСЦИПЛИНЕ «БАЗЫ ДАННЫХ»

Н.Е. СУРКОВА, М.И. Исмоилов



Введение

Методические указания предназначены для студентов четвертого курса специальности «Автоматизированные системы обработки информации и управления». Они помогают выполнить и оформить документацию к курсовому проекту.

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

Курсовой проект по дисциплине «БАЗЫ ДАННЫХ» предназначен для обучения студентов проектированию баз данных как элементов информационных систем, начиная с описания предметной области выбранного объекта и заканчивая реализованными базой данных и необходимыми пользовательскими интерфейсами.

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

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

Для выбора темы курсового проекта по дисциплине «БАЗЫ ДАННЫХ» необходимо определить область деятельности, которая наиболее хорошо знакома и интересна студенту. Тема курсового проекта является индивидуальной, т.е. если несколько студентов выбирают одну и ту же область деятельности, то для каждого из них должны быть указаны разные функции этой области деятельности. Примеры тем курсового проекта приведены в Приложении 1.

Заданием на курсовой проект является проектирование базы данных по выбранным функциям определенной области деятельности с помощью метода ER-диаграмм и CASE-средства ERwin.

Курсовой проект выполняется студентами в часы самостоятельной работы. Проект считается выполненным, если:

§ создана база данных в соответствии с требованиями метода ER-диаграмм (на электронном носителе);

§ спроектированы и реализованы пользовательские интерфейсы(на электронном носителе);

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

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

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

Содержание пояснительной записки к курсовому проекту

проектирование база данные информационный

Введение

1. Описание предметной области

2. Проектирование базы данных

2.1 Этап концептуального проектирования

2.1.1 Описание сущностей

2.1.2 Описание связей

2.1.3 Концептуальная модель данных

2.2 Этап логического проектирования

2.2.1 ER-диаграмма в среде ERwin

2.2.2 Анализ ER-диаграммы

2.2.3 Окончательная ER-диаграмма

2.3 Этап физического проектирования

2.3.1 Генерация базы данных

2.3.2 Схема данных в среде выбранной СУБД

3. Проектирование пользовательских интерфейсов

Заключение



Комментарии к содержанию пояснительной записки

Введение

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



1. Описание предметной области

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



2. Проектирование базы данных

Для проектирования базы данных используется одна из нотаций структурного метода - метод ER-диаграмм:

§ стандарт Чена - для построения концептуальной модели данных

§ стандарт IDEF1X - для CASE -средства ERwin.

Этап концептуального проектирования.

Задачей этапа концептуального проектирования БД является создание формализованного описания данных на основе описания предметной области - концептуальной модели данных (КМД). Создание КМД позволит автоматизировать процесс проектирования, давая возможность использовать различные CASE - средства.

Описание сущностей.

На этом шаге необходимо из описания предметной области выделить и описать все сущности.

Сущность - объект или концепция, которая характеризуется на данном предприятии как имеющая определенное существование.

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

· важно ли это существительное для выполнения заявленной функции данного объекта?

· имеет ли данное существительное дополнительное описание, которое требуется знать для реализации заявленной функции данного объекта?

Повторим, если на оба вопроса ответ будет положительным, то данное существительное - сущность.

Все выделенные сущности выписываются в таблицу описания сущностей. (Таблица № 2.1). Для имени сущности - идентификатора сущности - применяются следующие правила:

· оно должно быть недлинным, состоящим по возможности из одного слова;

· оно должно отражать суть сущности;

· оно не должно содержать специальных символов и пробелов. Пробелы можно заменить знаком подчеркивания - например:

o паспортные данные - не верно;

o №паспорта - не верно;

o пасп,данные - верно;

o пасп_дан - верно.

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

Таблица № 2.1

Описание сущностей

Сущность	Атрибуты	Ключи	Домен	Примечание
			тип	размер
1	2	3	4	5	6
1-я сущность	Ном_сущ	П	Целое полож.число	До 100000
	1-ый атрибут	Пт	текст	До 10 символов	По ум.- Москва
	2-й атрибут		Любое число	3 знака после запят.	Производный атрибут
	3-й атрибут	Пт	текст	До 10 символов	Понедельник; среда; пятница
2-я сущность (слабая сущность)	1-й атрибут		Дата/время
	2-й атрибут		денежный	До 10000000,00
№-я сущность	1-й атрибут	Пт-П	текст	До 15 символов
	2-й атрибут		Целое полож.число		100;10000;100000

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

Потенциальный ключ ( Пт ) - это атрибут, уникально характеризующий сущность, то есть одному значению потенциального ключа соответствует только один экземпляр сущности. У каждой сущности может быть один или несколько потенциальных ключей, может не быть ни одного потенциального ключа. Для каждой сущности указываются все потенциальные ключи, если они есть (см. таблицу № 2.1 - 3-я колонка). Для дальнейшего проектирования для каждой сильной сущности необходимо выбрать один первичный ключ. Слабая сущность не имеет собственного первичного ключа. Необходимо указать в таблице № 2.1 все слабые сущности (см. таблицу № 2.1 - 1-я колонка).

Первичный ключ ( П ) - это потенциальный ключ, отвечающий следующим условиям:

o принимает не очень большие (числовые) или длинные (текстовые) значения;

o вероятность изменения значений минимальна;

o вероятность потери уникальности в будущем минимальна;

o удобен с точки зрения пользователя для частого использования.

Если у сущности нет потенциальных ключей или все они не подходят под выше перечисленные условия, вводится дополнительный потенциальный ключ, как правило это номер данной сущности (например, Ном_док), который и будет первичным ключом. Первичный ключ тоже указывается в таблице 1 в колонке № 3 (см. таблицу № 2.1 - 3-я колонка).

Каждый атрибут имеет область допустимых принимаемых значений - домен, который необходимо указать. Домен делится на тип атрибута и размер и указывается в любой понятной и удобной проектировщику форме. На этом этапе можно, но не обязательно (а иногда и вредно) использовать стандартные типы данных, используемые в целевых СУБД. Если атрибут принимает только определенные конкретные значения, так называемый перечисляемый тип, то в колонке № 6 обязательно указываются все принимаемые значения (см. таблицу № 2.1 - 6-я колонка). Если атрибут может принимать значение по умолчанию - это значение фиксируется в колонке № 6 (см. таблицу № 2.1 - 6-я колонка).

Описание связей

На этом шаге необходимо найти все связи, существующие на проектируемом объекте и имеющие отношение к выделенной функции между описанными в таблице № 2.1 сущностями. Для этого заполняется таблица № 2.2.

Связь - осмысленная ассоциация между разными сущностями.

Для заполнения таблицы № 2.2 в колонку №1 записываются по порядку все сущности из таблицы № 2.1. В колонку №3, в строки, которые относятся к первой сущности, записываются все сущности по порядку начиная со второй.

Таблица № 2.2

Описание связей

Сущность	Связь	Сущность	Показатель кардинальности	Степень участия
				1-й сущности	2-й сущности
1	2	3	4	5	6
1-я сущность	Связаны1	2-я сущность	1:1	П	П
		3-я сущность
	Связаны2	4-я сущность	1:М	П	Ч
2-я сущность	Связаны5	2-я сущность	1:М	Ч	Ч
	Связаны3	3-я сущность	М:Н	Ч	П
3-я сущность	Связаны4	4-я сущность	1:М	П	Ч
	Связаны6	4-я сущность	М:Н	П	П

Далее в колонку №3, в строки, которые относятся ко второй сущности, записываются все сущности по порядку, начиная с третьей и так далее. После этого в колонку № 2 записывается глагол - имя связи, если между данными сущностями есть связь, и ничего не записывается, если связи нет.

Необходимо проверить, не связана ли каждая из сущностей из 1-й колонки сама с собой. Если для какой-либо сущности такая связь найдена, необходимо внести ее в таблицу № 2.2 (см. таблицу № 2.2. - связь под именем «связаны5»). Например, возможна связь между разными экземплярами одной и той же сущности «сотрудники» - «управляют». Эту связь тоже заносят в таблицу в виде: «сотрудники» - «управляют» - «сотрудники».

Возможна ситуация, когда для двух сущностей можно найти более одной связи. В этом случае необходимо убедиться, что найденные связи имеют важное значение для реализуемой функции и что они несут принципиально разную смысловую нагрузку. Если это так, то эти связи также включаются в таблицу (см. таблицу № 2.2.- связи «связаны4» и «связаны6»). Например, для сущности «сотрудники» можно найти связь «подчиняются », но данная связь является дублирующей (только в обратном прочтении) к приведенной ранее связи «сотрудники»-«управляют»-«сотрудники». Или, например, если была найдена связь «договор»-подписан»-«клиент», то связи «получает», «изучает» между этими сущностями не имеют большого значения и не включаются в таблицу.

Каждую связь характеризуют два структурных ограничения:

§ показатель кардинальности;

§ степень участия.

Показатель кардинальности описывает количество возможных связей для каждой сущности - участницы связи.

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

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

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

Результаты первого и второго шагов сравниваются, затем выбирается показатель кардинальности данной связи:

	Показатель кардинальности
Ответ на первом шаге	1:1	М:1
Ответ на втором шаге	1:М
Ответ на первом шаге	1:М	1:М
Ответ на втором шаге	1:1
Ответ на первом шаге	1:М	М:М
Ответ на втором шаге	1:М
Ответ на первом шаге	1:1	1:1
Ответ на втором шаге	1:1

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

Степень участия определяет, зависит ли существование некоторой сущности от участия в этой связи другой сущности.

Для определения степени участия необходимо задать вопрос: все ли экземпляры первой сущности принимают участие в заявленной связи? Если ответ - да, то степень участия первой сущности в этой связи - полная, если ответ - нет, то степень участия первой сущности в этой связи - частичная. Такой же вопрос задается и для второй сущности - участнице этой связи. Ответы заносятся в таблицу № 2.2.

ER-диаграмма

Используя данные таблиц № 2.1 и №2.2, создается концептуальная модель данных с использованием метода ER-диаграмм.

Для создания ER-диаграммы Чена:

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

Размещено на http://www.allbest.ru/

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

Размещено на http://www.allbest.ru/

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



Этап логического проектирования

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

2.2.1 ER-диаграмма в среде ERwin

Для построения ER-диаграммы в среде ERwin (стандарт IDEF1X) используют данные из таблиц № 2.1 и 2.2 или КМД, построенную на этапе концептуального проектирования.

При запуске среды ERwin необходимо внимательно заполнять все появляющиеся окна. В первом окне нужно выбрать режим создания новой модели или открыть существующую ER-диаграмму (см. рис. № 2.1).



Рис. 2.1 Вид 1-го окна при запуске CASE -средства ERwin

Во втором окне необходимо выбрать этапы проектирования, которые будут выполняться - для выполнения курсовой работы это этап Logical/Physical (см. рис. № 2.2), в этом случае становится активной нижняя часть окна, где необходимо выбрать целевую СУБД (на рис. № 2.2 - это SQL Server).

Рис. 2.2 Вид 2-го окна при запуске CASE -средства ERwin

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

При нажатии кнопки «ОК» во втором окне открывается рабочее окно в среде ERwin, имеющее несколько строк, приближенных по своему виду и функционалу к стандарту Microsoft Office (см. рис. № 2.3).

Первая строка - строка заголовка, содержащая имя (путь) файла, содержащего модель, которая в текущий момент находится в рабочем окне, по умолчанию modelN.er, где N - номер открываемого в среде ERwin окна по порядку. Первая строка имеет стандартные кнопки - свертывания, изменения размера и закрытия рабочего окна.

Вторая строка - строка главного меню - содержит все команды, которые можно выполнять в CASE-средстве Erwin, в том числе как привычные, например относящиеся к работе с файлами - «открыть», «сохранить», «сохранить как», так и специальные, например выбрать стандарт проектирования модели.

Рис. 2.3 Вид рабочего окна при запуске CASE -средства ERwin

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

Четвертая строка - так называемая панель форматирования, почти полностью повторяет стандарт Microsoft Office с добавлением кнопок «отмена действия нажатой кнопки», «создать сущность», «связь суперкласс/подкласс», «идентифицирующая связь», «связь многие-ко-многим», «неидентифицирующая связь». Именно с помощью этих кнопок создается модель (см. рис. № 2.4).

1 2 3 4 5

Рис. 2.4 Часть панели форматирования с кнопками для создания модели

Для отображения сущности необходимо нажать кнопку 1 (см. рис. № 2.4), указатель курсора поменяет свой вид на крестик, что позволит, щелкнув мышью, показать местоположение в рабочем окне сущности. В рабочем окне появится:

Сущность отображается прямоугольником, разделенным на две части. Над прямоугольником выделено имя и номер сущности - Е/5 (сущность - Entity № 5). Выделение говорит о том, что мы можем изменить имя сущности, просто набирая на клавиатуре нужное нам:

Обратите внимание - размер прямоугольника изменится таким образом, чтобы имя сущности читалось целиком. Размер и положение сущности меняется привычным в Microsoft Office способом работы с объектами. Если необходимо изменить имя сущности - щелкните дважды по нему мышью, появится окно работы с сущностью - рис.2.5, и в строке Name можно вписать другое имя.

Рис. 2.5 Изменение имени в окне работы с сущностью

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

Blob - логический и OLE-тип,

Datetime - время-дата,

Number - числовой,

String - символьный тип.

Для работы с введенными атрибутами - изменения имени, уточнения типа, удаления атрибута, а также для указания, является ли выбранный атрибут первичным ключом, значения атрибута по умолчанию - открывается окно работы с атрибутами - рис. 2.7.

Рис. 2.6 Добавление нового атрибута в окне ввода атрибута

На рис. 2.7. показано назначение введенного атрибута «Табном» сущности «Персонал» первичным ключом. При нажатии на кнопки, расположенные в нижней части окна, можно:

New… - открыть окно ввода нового атрибута;

Rename… - изменить имя выбранного атрибута;

Delete - удалить выбранный атрибут.

Для уточнения типа атрибута, для указания значения атрибута по умолчанию в правой части окна работы с атрибутами выбирается вкладка Datatype. На рис. 2.8. показано, что для атрибута FIO тип принимается как varchar (55) - не более 55 символов.

Необходимо отметить, что первичный ключ располагается в верхней части прямоугольника («на крыше»), все остальные атрибуты - в нижней. Можно указателем мыши переносить атрибуты «с крыши» вниз и наоборот, меняя таким образом первичный ключ.

Рис. 2.7 Окно работы с атрибутами

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

У изображения сущности можно менять шрифт, его размер, цвет шрифта, цвет фона и линий аналогично тому, как это делается в среде Microsoft Word.

Для установления связей между сущностями необходимо пользоваться кнопками 2-5 (см. рис.2.4.).

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

Для отображения связей с показателями кардинальности 1хМ и 1х1 используют:

кнопку 4 - «идентифицирующая связь», она переводит первичный ключ сущности с кардинальностью «1» в качестве обычного, внешнего атрибута в сущность с кардинальностью «М»;

кнопку 5 - «неидентифицирующая связь», она переводит первичный ключ сущности с кардинальностью «1» в качестве первичного, внешнего атрибута в сущность с кардинальностью «М».

Рис. 2.8 Уточнение типа атрибута



Рис. 2.9 Отображение сущности в CASE-средстве Erwin

Для того, чтобы зафиксировать свойства связи, используют окно «Свойства связи» (Relationship Property), вызываемое из контекстного меню правой кнопки мыши одноименной строчкой (см. рис.2.10).

В этом окне указывается имя связи: в нашем примере - «заключает» и степень участия в этой связи сущности с кардинальностью «1», так называемой «родительской» сущности: в нашем примере - экземпляры сущности «Персонал» могут не принимать участие в связи «заключает», то есть не заключать договора ( например, лаборанты ), а могут принимать, то есть заключать М договоров. Если же все экземпляры сущности «Персонал» принимают участие в связи «заключает», то необходимо выбрать строчку “One or More (P)”.

Для связи с показателем кардинальности 1х1 выбираются строки “Zero or One (Z)” и “Exactly”. Если выбирается строка “Zero or One (Z)”, экземпляры сущности «Персонал» могут не принимать участие в связи «заключает», то есть не заключать договора, а могут принимать, то есть заключать, только 1 договор. Если выбирается строка “Exactly”, необходимо указать конкретную цифру. В этом случае экземпляры сущности «Персонал» обязательно принимают участие в связи и заключают конкретное количество договоров.



Рис. 2.10 Окно «Свойства связи» в CASE-средстве Erwin

Если две сущности связаны друг с другом двумя или более разными связями, а также в случае рекуррентных (ролевых) связей, необходимо указать ролевые имена, с которыми эти сущности вступают в связь. Для этого в окне «Свойства связи» (Relationship Property) открывают вкладку «Ролевые имена» (Rolename) (см. рис. 2.11) и в строке «Ролевое имя» (Rolename) указывают имя - в данном примере для связи «доставляют» ролевое имя - «курьер». Ролевое имя используется в качестве имени внешнего атрибута, по которому передается первичный ключ.

Для отображения связи «суперкласс-подкласс» используется кнопка 3. При этом сначала щелкают мышью по кнопке 3 - выбирают тип связи, затем щелкают по сущности-суперклассу, затем по сущности-подклассу. Если у сущности-суперкласса есть несколько сущностей-подклассов, то для их включения используется кнопка 4, сначала щелкают по кнопке, затем - по значку связи, а затем - по сущности-подклассу. Для связи «суперкласс-подкласс» необходимо указать степень вхождения подклассов в суперкласс в окне “Subtype Relationships” (см. рис. 2.12), вызываемое правой кнопкой мыши. “Complete” - сущность-суперкласс состоит только из экземпляров сущностей-подклассов; “Incomplete” - сущность-суперкласс состоит не только из экземпляров сущностей-подклассов. На рис. 2.12. изображен пример неполного вхождения сущностей-подклассов в сущность-суперкласс: «Персонал» состоит не только из «Менеджеры» и «Операторы».

Рис. 2.11 Вкладка “Ролевые имена” (“Rolename”)

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

Для отображе6ния связи с показателем кардинальности МхМ используется кнопка 5. Передача ключа при этой связи не происходит (см. рис. 2.13).

При отображении всех сущностей и связей, заявленных в таблицах

2.1 и 2.2., получается ER- диаграмма в стандарте IDEF1X.

Рис. 2.12 Окно “Subtype Relationships”

2.2.2 Анализ ER- диаграммы

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

Многозначные атрибуты - меняются на сущность с именем многозначного атрибута и связь с показателем кардинальности «1 х М». См. рис. 2.13 - атрибут «телефон» сущности «Клиент» заменен на сущность «Телефон». Обратите внимание, что в сущности «Клиент» такого атрибута уже нет.

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

Рекурсивные связи - возможно требуют добавления сущности или сущности-подкласса и связи с показателем кардинальности «1 х М».

Связи с показателем кардинальности «1 х 1» - требуют дополнительного анализа, действительно ли это две разные сущности или возможно объединение в одну сущность.

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

Связи с показателем кардинальности «М х N» - анализируются на наличие собственных атрибутов.

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

2.3 Этап физического проектирования

Этап физического проектирования всегда тесно связан с особенностями конкретной выбранной СУБД.



Рис. 2.12 Пример связи с показателем кардинальности МхМ

2.3.1 Генерация базы данных

На этапе физического проектирования в ER-диаграмме для всех атрибутов уточняются все типы данных, чтобы убедиться в их применении в выбранной среде реализации. Для этого в CASE-средстве Erwin достаточно выбрать физический этап проектирования в пиктографическом меню (см. рис. 2.14). Все имеющиеся связи с показателем кардинальности «М х N» раскрываются в ассоциативные таблицы. Чтобы получить ассоциативную таблицу, необходимо поставить курсор на связь с показателем кардинальности «М х N»и нажать на правую кнопку мыши, выбрать из всплывающего меню строчку ”Create Аssociative Table” и последовательно нажимать «OK» во всех диалоговых окнах. Пример вида окончательной ER-диаграммы представлен на рис. 2.13.



Рис. 2.13 Пример ER-диаграммы на этапе физического проектирования

Для генерации таблиц и схемы данных в выбранной СУБД необходимо выполнить следующие действия:

cоздать пустой файл базы данных;

выполнить команду “DataBase” - “DataBaseConnection” и в появившемся диалоговом окне в строке “DataBase” выбрать полный путь к созданному пустому файлу;

выполнить команду “Tools” - “Forward Engineer” - «OK».

Рис. 2.14 Переход к физическому этапу проектирования



3. Проектирование пользовательских интерфейсов

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

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

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

3.1 Список требований пользователей

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

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

Менеджер:

Список всех операторов.

Перечень всех договоров конкретного менеджера за конкретный месяц.

Поиск информации об операторе по его ФИО.

Оператор:

Ввод нового договора.

Поиск объекта по цене.

Ввод нового клиента.

Поиск всех договоров конкретного клиента.

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

Продавец:

Поиск товара по названию и цене «от» - «до»

Поиск товара по марке-производителю.

Формирование чека.

Список всех своих чеков за период.

Невозможны в этом случае транзакции:

Продавец:

Ввод нового товара - относится к описанию функции поставок.

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

Для включения в специализацию транзакций при выполнении курсового проекта следует избегать транзакций типа Delete (удаление) и типа Update (обновление).

3.2 Анализ транзакций на этапе логического проектирования

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

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

Для примера рассмотрим анализ всех транзакций, заявленных менеджером.

Список всех операторов.

Для выполнения данной транзакции необходимо найти значение первичного ключа - номера данного менеджера среди значений данного атрибута сущности «Менеджеры». Если такой номер не будет найден, необходимо вывести сообщение о том, что такого менеджера не существует. Если будет найден, далее необходимо найти связь с сущностью «Операторы». Такая связь есть через сущность «Персонал», но эта связь не позволяет определить, кто из персонала подчиняется данному менеджеру. Данную транзакцию выполнить нельзя. Необходимо добавить связь «Менеджеры» - «управляют» - «Операторы», показатель кардинальности которой «1 х М». В этом случае по этой связи мы найдем данные обо всех операторах в сущности «Операторы», у которых значение атрибута “Таб_ном_мен” равен заявленному. Результат анализа данной транзакции и все необходимые исправления модели данных приведены на рис. 3.1.

Перечень всех договоров конкретного менеджера за конкретный месяц.

Для выполнения данной транзакции необходимо найти значение первичного ключа - номера данного менеджера в сущности «Персонал», далее найти значения всех атрибутов в сущности «Договор», где значение атрибута “менеджер” совпадает с заданным и значение атрибута “Дата_закл” попадает в границы заданного месяца. Данная транзакция может быть выполнена. Результат анализа данной транзакции и все необходимые исправления модели данных приведены на рис. 3.1.

Поиск информации об операторе по его ФИО.

Для выполнения данной транзакции необходимо найти заданное значение атрибута “FIO” в сущности «Персонал». Если такого значения нет, необходимо вывести сообщение об ошибке, если таких значений одно или больше, а это возможно, так как атрибут “FIO” не является первичным ключом, и для всех этих значений необходимо найти значения первичных ключей «Таб_ном» и всех остальных атрибутов, так как они содержат данные об искомых операторах, и далее найти значения всех атрибутов в сущности-подклассе «Операторы», где значения первичных ключей совпадают с найденными. Данная транзакция может быть выполнена. Результат анализа данной транзакции и все необходимые исправления модели данных приведены на рис. 3.1.

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

Документация на пользовательские интерфейсы.

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



Рис. 3.1 Пример визуального отображения анализа транзакций на этапе логического проектирования

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

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

Постановка задачи.

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

ПИ обеспечивает деятельность оператора по заключению договора на аренду жилья:

Поиск или ввод клиента;

Поиск объектов жилья по требованию клиента:

По ближайшей станции метро и/или цене «от»-«до»;

По количеству комнат и/или метражу жилой площади;

По наличию телефона и/или мебели;

Оформление договора.

Исходные данные.

Исходные для ПИ данные делятся на:

Переданные из БД.

Обычно в ПИ оформляются как поля ввода (текстовые поля). Необходимо перечислить все поля ПИ, которые содержат данные из БД и указать из какой таблицы (поле) они берутся. Например:

Поле «Полный адрес объекта» берется из таблицы Объект(Адрес)

Поля ФИО, дата рождения, прописка клиента - таблица Клиент(ФИО, Д_рож, адрес)

Поля Паспортные данные - таблица Паспорт(номер, серия, кто, когда)

Поле Стоимость - таблица Объект(ст-ть)

Количество месяцев.

Введенные вручную.

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

ФИО клиента

Номер и серия паспорта

Цена «от»

Цена «до»

Начало аренды

Конец аренды.

Справочные константы.

Обычно в ПИ оформляются как метки, поля ввода (текстовые поля) с уже введенными данными, поля со списком выбора, метки с «переключателем». Необходимо перечислить все поля ПИ, которые содержат справочную информацию и ее источник. Например:

ближайшая станция метро - список всех станций метрополитена.



3.3.3 Алгоритм решения

Если в ПИ проводятся какие-либо вычисления, необходимо пояснить их алгоритм либо в виде формул, либо в виде блок-схемы, либо в виде текста с пояснениями. Например:

стоимость по договору = стоимость * количество месяцев

количество месяцев = конец аренды - начало аренды.

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

3.3.4 Макет интерфейса

Если ПИ имеет только одну экранную форму - представлять нужно только ее, если несколько - представлять нужно все формы с указанием условий переходов и возвратов от одной формы к другой. Например:

Рис. 3.2 Макет пользовательского интерфейса

3.3.5 Перечень всех управляющих элементов макета

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

Таблица №3.1

Описание управляющих элементов

Номер управляющего элемента	Имя элемента	Какие действия выполняются
ComboBox1		Позиционирование конкретного оператора
Buttom1	Найти	Поиск данных о клиенте по номеру и серии паспорта
Buttom2	Добавить клиента	Добавление данных о новом клиенте
Buttom3	Просмотреть список договоров клиента	Просмотр всех договоров найденного клиента
ComboBox2		Выбор станции метро из всего списка станций
ComboBox3		Выбор количества комнат из возможного в компании списка (1,2,3,4)
ComboBox4		Выбор типа дома из возможного в компании списка.
Buttom4	Найти	Поиск варианта квартиры по одному или любому набору представленных параметров.
ComboBox5		Выбор месяца
Buttom5	Заключить договор	Добавление данных нового договора. В результате добавления в окне «Номер договора» автоматически появится следующий номер договора. В окне «Количество договоров за день» происходит увеличение на 1. В окне «на сумму» происходит увеличение на сумму добавленного договора.
Buttom6	Распечатать договор	Происходит распечатка шаблона договора, хранящегося в MSWord с добавлениями полей таблицы «Договор»

Программный код.

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

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

Реализация транзакций средствами выбранной СУБД.

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

В курсовой проект включаются 10 реализованных средствами СУБД транзакций. Описание реализованных транзакций делается в виде таблицы (см. таблицу №3.2)

Таблица №3.2

Описание реализованных в СУБД MS Access транзакций

Имя или номер транзакции по спецификации транзакции	Форма реализации	Имя реализации.
Т12. Выбор сотрудников с должностью оператор	Запрос	Операторы
Т27. Список договоров, содержащий информацию об арендованных объектах	Сохраняемый запрос	Список_договоров

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

Анализ транзакций на этапе физического проектирования.

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

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

ожидаемая частота выполнения транзакций;

отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а также тип этого доступа ( R - выборка, I - вставка, U - обновление, D - удаление );

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

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

Сущности	Количество входящих стрелочек
Персонал	3
Менеджеры	1
Операторы	2
Договор	1

Так как в нашем примере анализировалось небольшое количество транзакций, то количество входящих стрелочек для всех сущностей примерно одинаково. Обычно 2-3 сущности имеют значительно большее количество, чем все остальные. На этапе физического проектирования целесообразно анализировать только те транзакции, которые включают обращения к отношениям с большим количеством входящих стрелочек. В нашем случае это сущности «Персонал» и «Операторы», через которые проходят все заявленные в нашем примере транзакции. Обычно остается для анализа на физическом этапе проектирования около 80% всех транзакций.

Далее необходимо указать ожидаемое количество строк в отношениях, а также среднюю и максимальную кратности каждой связи (см. рис. №3.3). Например, ожидается, что персонал компании составит 50 человек, 4 из которых менеджеры, 40 операторов. Компания владеет 500 объектами жилья, на которые заключается 1000 договоров.

Рис. № 3.3 Указание ожидаемой размерности отношений и связи

При анализе каждой из транзакций очень важно знать не только среднее и максимальное количество ее вызовов в час, но и иметь сведения о тех днях недели и часах суток, когда она обычно выполняется, включая и данные о времени пиковой нагрузки. Например, частота вызова некоторых транзакций может удерживаться на некотором уровне постоянно, но все же она имеет четко выраженный пик нагрузки в последний четверг месяца с 14-00 до 16-00, вызванный подготовкой отчетов. Другие транзакции вообще могут выполняться только в определенные моменты времени, например - по понедельникам с 9-00 до 10-00, что также является пиком нагрузки.

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

Таблица № 3.3

Результаты анализа

Тран закция	Актив-ность	День недели	Время суток	Частота вызовов в месяц
Т1. Список всех операторов	Пиковая	-	-	-
	Средняя	Понедельник	9-00 - 12-00	1
От отношения	К отношению	Атрибуты	Тип доступа	Частота вызовов в месяц
-	Менеджер	Таб-ном	R(E)	1
Менеджер	Оператор	Таб-ном-мен Таб-ном	R(E)*	10 - 15
Оператор	Персонал	Таб-ном *	R(E) R
Тран закция	Актив-ность	День недели	Время суток	Частота вызовов в месяц
Т2. Перечень всех договоров конкретного менеджера за конкретный месяц.	Пиковая	Последний четверг месяца	9-00 - 12-00	4
	Средняя	-	-	-
От отношения	К отношению	Атрибуты	Тип доступа	Частота вызовов в месяц
-	Персонал	Таб-ном	R(E)	4
Персонал	Договор	Таб-ном *	R(E)* R	800 - 1200
Тран закция	Актив-ность	День недели	Время суток	Частота вызовов в месяц
Т3. Поиск информации об операторе по его ФИО	Пиковая	Последний четверг месяца	15-00 - 16-00	40
	Средняя	Понедельник-пятница	Случайным образом	20
От отношения	К отношению	Атрибуты	Тип доступа	Частота вызовов в месяц
-	Персонал	FIO *	R(E) R	60



Заключение

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

Мнение студента о проделанной работе;

Отношение к изученному материалу;

Оценку средств и методов проектирования.

Приложение 1

Список возможных тем курсового проекта.

1. Проектирование БД учета продаж новых автомобилей в автосалоне.

2. Проектирование БД учета продаж подержанных автомобилей.

3. Проектирование БД учета продаж микроавтобусов.

4. Проектирование БД учета автомобилей в автостоянке.

5. Проектирование БД учета ремонта автомобилей в автосервисе.

6. Проектирование БД учета угнанных автомобилей в ГИБДД.

7. Проектирование БД учета ДТП.

8. Проектирование БД учета проката яхт.

9. Проектирование БД учета продаж видео-, аудио продукции.

10. Проектирование БД учета автоперевозок грузов.

11. Проектирование БД учета авиаперевозок грузов.

12. Проектирование БД учета авиаперевозок пассажиров.

13. Проектирование БД учета поселения гостей в гостинице.

14. Проектирование БД учета свободных номеров в гостинице.

15. Проектирование БД обслуживания посетителей в ресторане.

16. Проектирование БД обслуживания посетителей в баре.

17. Проектирование БД учета посетителей в поликлинике.

18. Проектирование БД учета записей на прием к врачам.

19. Проектирование БД учета лекарств в аптеке

20. Проектирование БД учета работ с клиентами в фирме страхования.

21. Проектирование БД работы с клиентами в фирме недвижимости.

22. Проектирование БД учета выдачи книг в библиотеке.

23. Проектирование БД учета поступлений и списаний книг в библиотеке.

24. Проектирование БД учета денежных переводов.

25. Проектирование БД учета розничной торговли.

26. Проектирование БД учета оптовой торговли.

27. Проектирование БД организации складского хозяйства.

28. Проектирование БД учета торговли на заказ.

29. Проектирование БД торговли через Интернет.

30. Проектирование БД учета продаж театральных билетов.

31. Проектирование БД сессии в ВУЗе.

32. Проектирование БД учета продаж продукций цементного завода.

33. Проектирование БД учета продаж продукций кирпичного завода

34. Проектирование БД учета продаж продукций мебельной фабрики.

35. Проектирование БД учета продаж продукций издательства(книги).

36. Проектирование БД учета продаж продукций кондитерской фабрики

37. Проектирование БД учета продаж газет и журналов.

38. Проектирование БД учета вызовов службы скорой помощи

39. Проектирование БД учета вызовов МЧС.

40. Проектирование БД учета продаж авиабилетов.

41. Проектирование БД учета продаж ж/д билетов.

42. Проектирование БД для мостостроительной компании.

43. Проектирование БД для дорожно-строительной компании.

44. Проектирование БД учета заявок клиентов ЖКХ.

45. Проектирование БД для спортивного общества

46. Проектирование БД учета клиентов туристической компании.

47. Проектирование БД учета клиентов коммерческого банка

48. Проектирование БД для компании по продаже оргтехники.

49. Проектирование БД для компании по ремонту оргтехники.

50. Проектирование БД для компании по ремонту телефонов.

51. Проектирование БД учета клиентов фитнес-клуба.

52. Проектирование БД учета продаж/услуг почтового отделения

53. Проектирование БД «авто/моторалли».

54. Проектирование БД для картинной галереи.

55. Проектирование БД для ветеринарной клиники.

56. Проектирование БД для модельного агентства.

57. Проектирование БД для фотостудии.

58. Проектирование БД для звукостудии.

59. Проектирование БД для ломбарда

60. Проектирование БД для трудовой биржы.

61. Проектирование БД для бюро находок.

62. Проектирование БД для Интерпол

63. Проектирование БД для бюро знакомств.

64. Проектирование БД для салона сотовой связи.

65. ….

66. ….

67. ….….



Приложение 2

Пример оформления пояснительной записки к курсовому проекту.

МОСКОВСКИЙ АВТОМОБИЛЬНО-ДОРОЖНЫЙ

ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

(МАДИ)

Пояснительная записка к курсовому проекту

по дисциплине

«БАЗЫ ДАННЫХ»

на тему

«Проектирование базы данных для автосервиса»

Выполнил студент: Иванов Д.И., гр.4АСУ1

Проверил: к.т.н., доц. Исмоилов М.И.

Москва 2012



Введение

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

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

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

Задачи проекта

Исследование и описание предметной области.

Применение метода ER-диаграмм для разработки базы данных.

Использование CASE - средства Erwin для анализа модели и автоматической генерации БД.

Создание макета сценарного интерфейса для пользователя.



1. Описание предметной области

Объект: автосервис

Функция: предоставления ремонтных услуг

У нас выполняются услуги:

§ замена расходных материалов (масло, колодок, фильтров)

§ тонировка

§ установка ксенона

§ установка сигнализации

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

Имеются автомасла, фильтры, колодки таких известных отечественных и зарубежных производителей, как Luxoil (Люксойл), Oil Right, Лукойл, ТНК, Spectrol (Спектрол), BP, Shell (Шелл), Mobil (Мобил), Mannol (Маннол), Zic (Зик), Esso (Эссо), Castrol (Кастрол), вся замена происходит в течении двух часов.

Тонировать стекло автомобиля можно только все сразу, нельзя за тонировать одно стекло, т.к будет различие в оттенке пленки. Стоимость тонировки составляет 5000 рублей. Работа осуществляется в течении одного рабочего дня.

Стоимость материалов суммируется со стоимостью работы, которая составляет 500 рублей.

Услуги в автосервисе выполняются мастером - универсалом и любой мастер может выполнить любую услугу, которая осуществляется в нашем автосервисе.

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