МИНИСТЕРСТВО ОБРАЗВОАНИЯ И НАУКИ РФ КАБАРДИНО

1
МИНИСТЕРСТВО ОБРАЗВОАНИЯ И НАУКИ РФ
КАБАРДИНО-БАЛКАРСКИЙ ИНСТИТУТ БИЗНЕСА
КАФЕДРА ВЫСШЕЙ МАТЕМАТИКИ И ИНФОРМАТИКИ
БАЗЫ ДАННЫХ
Методические указания по курсовому проектированию по дисциплине
Нальчик
2012
2
Составитель: Д.А.Анисимов., к.г.н., зав.кафедрой Высшей математики и информатики.
Рецензенты:
Хакулов В.А., д.т.н., проф. Кафедры ВМИ КБИБ
Биссоков Р.М., доц. Кафедры ВМИ КБИБ
3
Введение
Методические указания предназначены для студентов специальности
080801.65
«Прикладная информатика в менеджменте», и направления 230700.62 «Прикладная
информатика», профиля «Прикладная информатика в менеджменте». Они помогают выполнить и
оформить документацию к курсовому проекту.
Курсовой проект имеет целью научить студентов самостоятельно применять полученные
знания для комплексного решения конкретных теоретических и практических задач, привить
навыки самостоятельного проведения научных исследований.
Курсовой проект по дисциплине «Базы данных» предназначен для обучения студентов
проектированию баз данных как элементов информационных систем, начиная с описания
предметной области выбранного объекта и заканчивая реализованными базой данных и
необходимыми пользовательскими интерфейсами.
За время работы над курсовым проектом студент получает практические навыки ведения
проекта и оформления сопутствующей документации, умения создавать и анализировать модели
баз данных, использования структурного метода проектирования, работы в специализированном
CASE-средстве ERwin.
Темы курсовых проектов разрабатываются преподавателями в соответствии с основным
содержанием учебной дисциплины и согласовываются со студентом по его желанию,
рассматриваются и утверждаются на заседании кафедры.
Для выбора темы курсового проекта по дисциплине «Базы данных» необходимо
определить область деятельности, которая
наиболее хорошо знакома и интересна студенту.
Тема курсового проекта является индивидуальной, т.е. если несколько студентов выбирают одну
и ту же область деятельности, то для каждого из них должны быть указаны разные функции этой
области деятельности. Примеры тем курсового проекта приведены в Приложении 1.
Заданием на курсовой проект является проектирование базы данных по выбранным
функциям определенной области деятельности с помощью метода ER-диаграмм и CASE-средства
ERwin.
Курсовой проект выполняется студентами в часы самостоятельной работы. Проект
считается выполненным, если:

создана база данных в соответствии с требованиями метода ER-диаграмм (на
электронном носителе);

спроектированы и реализованы пользовательские интерфейсы(на электронном
носителе);

подготовлена и оформлена в виде пояснительной записки вся необходимая
документация.
Курсовой проект выносится на открытую защиту перед преподавателем (комиссией). В
ходе защиты студент демонстрирует и доказывает работоспособность проекта и его
экономическую привлекательность. По результатам его защиты студенту выставляется оценка.
При получении неудовлетворительной оценки они выполняют работу по новой теме или
перерабатывают прежнюю в сроки, устанавливаемые деканом факультета.
4
Содержание пояснительной записки к курсовому проекту.
Введение.
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. Проектирование пользовательских интерфейсов.
Заключение.
5
Комментарии к содержанию пояснительной записки.
Введение
Во введении студент в произвольной форме описывает выбранный объект, анализирует
основные функции его деятельности, выделяет те функции и тех пользователей, для которых
будет проектироваться информационная система. Желательно также пояснить причину выбора
конкретных объекта и функций.
1. Описание предметной области
В произвольной форме на языке деловой прозы необходимо подробно изложить, как и
кем выполняются заявленные функции, какие бизнес-правила существуют на выбранном объекте,
относящиеся к выполнению выбранных функций, какие входные документы используются, какие
выходные документы формируются и куда направляются. В описании предметной области
приводятся примеры всех документов, которые используются для реализации выбранных
функций.
2. Проектирование базы данных.
Для проектирования базы данных используется одна из нотаций структурного метода –
метод ER-диаграмм:

стандарт Чена - для построения концептуальной модели данных

стандарт IDEF1X - для CASE –средства ERwin.
Этап концептуального проектирования.
Задачей этапа концептуального проектирования БД является создание формализованного
описания данных на основе описания предметной области – концептуальной модели данных
(КМД). Создание КМД позволит автоматизировать процесс проектирования, давая возможность
использовать различные CASE – средства.
Описание сущностей.
На этом шаге необходимо из описания предметной области выделить и описать все
сущности.
Сущность – объект или концепция, которая характеризуется на данном предприятии как
имеющая определенное существование.
Другими словами, из описания предметной области выделяются все существительные и
устойчивые словосочетания. Далее необходимо определить, для каких из выделенных
существительных ответ будет положительным на следующие вопросы:

важно ли это существительное для выполнения заявленной функции данного
объекта?

имеет ли данное существительное дополнительное описание, которое требуется
знать для реализации заявленной функции данного объекта?
Повторим, если на оба вопроса ответ будет положительным, то данное существительное –
сущность.
Все выделенные сущности выписываются в таблицу описания сущностей. (Таблица № 2.1).
Для имени сущности – идентификатора сущности - применяются следующие правила:

оно должно быть недлинным, состоящим по возможности из одного слова;

оно должно отражать суть сущности;

оно не должно содержать специальных символов и пробелов. Пробелы можно
заменить знаком подчеркивания – например:
o
паспортные данные – не верно;
o
№паспорта – не верно;
o
пасп,данные – верно;
6
o
пасп_дан – верно.
Такие же правила используются и для назначения имен атрибутов.
Таблица № 2.1 Описание сущностей.
Сущность
Атрибуты
Ключи
1
1-я сущность
2
Ном_сущ
1-ый атрибут
2-й атрибут
3
П
Пт
3-й атрибут
Пт
2-я сущность
(слабая
сущность)
№-я сущность
1-й атрибут
2-й атрибут
1-й атрибут
2-й атрибут
Домен
тип
размер
4
5
Целое полож.число До 100000
текст
До 10 символов
Любое число
3 знака после
запят.
текст
До 10 символов
Дата/время
денежный
Пт-П
Примечание
6
По ум.- Москва
Производный атрибут
Понедельник;
среда; пятница
До 10000000,00
текст
До 15 символов
Целое полож.число
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-я колонка). Если
7
атрибут может принимать значение по умолчанию – это значение фиксируется в колонке № 6 (см.
таблицу № 2.1 – 6-я колонка).
Описание связей
На этом шаге необходимо найти все связи, существующие на проектируемом объекте и
имеющие отношение к выделенной функции между описанными в таблице № 2.1 сущностями.
Для этого заполняется таблица № 2.2.
Связь – осмысленная ассоциация между разными сущностями.
Для заполнения таблицы № 2.2 в колонку №1 записываются по порядку все сущности из
таблицы № 2.1. В колонку №3, в строки, которые относятся к первой сущности, записываются
все сущности по порядку начиная со второй.
Таблица № 2.2 Описание связей
Сущность
Связь
Сущность
1
2
3
1-я сущность
2-я сущность
3-я сущность
Связаны1
Показатель
кардинальности
4
Степень участия
1-й сущности 2-й сущности
5
6
1:1
П
П
Связаны2
Связаны5
Связаны3
Связаны4
2-я сущность
3-я сущность
4-я сущность
2-я сущность
3-я сущность
4-я сущность
1:М
1:М
М:Н
1:М
П
Ч
Ч
П
Ч
Ч
П
Ч
Связаны6
4-я сущность
М:Н
П
П
Далее в колонку №3, в строки, которые относятся ко второй сущности, записываются все
сущности по порядку, начиная с третьей и так далее. После этого в колонку № 2 записывается
глагол – имя связи, если между данными сущностями есть связь, и ничего не записывается, если
связи нет.
Необходимо проверить, не связана ли каждая из сущностей из 1-й колонки сама с собой.
Если для какой-либо сущности такая связь найдена, необходимо внести ее в таблицу № 2.2 (см.
таблицу № 2.2. – связь под именем «связаны5»). Например, возможна связь между разными
экземплярами одной и той же сущности «сотрудники» - «управляют». Эту связь тоже заносят в
таблицу в виде: «сотрудники» - «управляют» - «сотрудники».
Возможна ситуация, когда для двух сущностей можно найти более одной связи. В этом
случае необходимо убедиться, что найденные связи имеют важное значение для реализуемой
функции и что они несут принципиально разную смысловую нагрузку. Если это так, то эти связи
также включаются в таблицу (см. таблицу № 2.2.- связи «связаны4» и «связаны6»). Например, для
сущности «сотрудники» можно найти связь «подчиняются », но данная связь является
дублирующей (только в обратном прочтении) к приведенной ранее связи «сотрудники»«управляют»-«сотрудники». Или, например, если была найдена связь «договор»-подписан»«клиент», то связи «получает», «изучает» между этими сущностями не имеют большого значения
и не включаются в таблицу.
Каждую связь характеризуют два структурных ограничения:

показатель кардинальности;

степень участия.
Показатель кардинальности
описывает количество возможных связей для каждой
сущности - участницы связи.
8
Для нахождения показателя кардинальности необходимо использовать следующее правило,
состоящее из трех шагов.
Выделяется один экземпляр первой сущности и проверяется, со сколькими экземплярами
второй сущности он может вступать в связь. При этом не учитывается временной фактор,
другими словами - со сколькими экземплярами второй сущности он может вступать в связь в
любое время.
Выделяется один экземпляр второй сущности и проверяется, со сколькими экземплярами
первой сущности он может вступать в связь в любое время.
Результаты первого и второго шагов сравниваются, затем
выбирается показатель
кардинальности данной связи:
Показатель
кардинальности
Ответ на первом шаге
Ответ на втором шаге
Ответ на первом шаге
Ответ на втором шаге
Ответ на первом шаге
Ответ на втором шаге
Ответ на первом шаге
Ответ на втором шаге
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-диаграммы Чена:

сильные сущности отображаются прямоугольниками с именем сущности внутри
прямоугольника с обязательным указанием первичного ключа, который находится в овале,
связанном с прямоугольником. Имя первичного ключа в овале подчеркивается для отличия
первичного ключа от обычного атрибута. Например,
Сотрудники
Табномер

слабые сущности отображаются двойными прямоугольниками с именем сущности
внутри прямоугольника без указания первичного ключа. Например,
9
Паспорт

связь отображается ромбом с именем связи внутри. Ромб линиями соединяется с
прямоугольниками связанных сущностей. Одна линия – частичная степень участия, две линии –
полная степень участия. Над каждой линией ставится показатель кардинальности. Например,
1
Сотрудники
1
Паспорт
имеет
Табномер
Этап логического проектирования
Задачей этапа логического проектирования БД является создание такой логической модели
данных, которая, с одной стороны, соответствует описанию предметной области, а с другой,
отвечает всем требованиям целевой СУБД, которая выбирается (или используется как
существующая) на этом этапе проектирования.
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).
10
Рис. 2.2. Вид 2-го окна при запуске CASE –средства ERwin.
При такой настройке можно будет работать на логическом и физическом этапах
проектирования в среде ERwin, более того, на этапе физического проектирования ERwin будет
поддерживать типы данных выбранной СУБД и автоматически переносить разработанную
структуру базы данных в выбранную СУБД.
При нажатии кнопки «ОК» во втором окне открывается рабочее окно в среде ERwin,
имеющее несколько строк, приближенных по своему виду и функционалу к стандарту Microsoft
Office (см. рис. № 2.3).
Первая строка – строка заголовка, содержащая имя (путь) файла, содержащего модель,
которая в текущий момент находится в рабочем окне, по умолчанию modelN.er, где N - номер
открываемого в среде ERwin окна по порядку. Первая строка имеет стандартные кнопки –
свертывания, изменения размера и закрытия рабочего окна.
Вторая строка – строка главного меню - содержит все команды, которые можно выполнять
в CASE-средстве Erwin, в том числе как привычные, например относящиеся к работе с файлами
- «открыть», «сохранить», «сохранить как», так и специальные, например выбрать стандарт
проектирования модели.
11
Рис. 2.3. Вид рабочего окна при запуске CASE –средства ERwin.
Третья строка – пиктографическое меню, на которое выведены иконки наиболее часто
используемых команд – работа с файлами («создать», «открыть», «сохранить», «распечатать»),
изменение уровня отображения модели (уровень сущности, уровень атрибутов, уровень описания),
масштабирования отображения модели (мельче, крупнее) и выбор этапа проектирования.
Необходимо убедиться, что нажата кнопка «уровень атрибутов», при котором отображается не
только сама сущность, но и все ее атрибуты, а также что вы находитесь на логическом этапе
проектирования.
Четвертая строка - так называемая панель форматирования, почти полностью повторяет
стандарт Microsoft Office с добавлением кнопок «отмена действия нажатой кнопки», «создать
сущность», «связь суперкласс/подкласс», «идентифицирующая связь», «связь многие-ко-многим»,
«неидентифицирующая связь». Именно с помощью этих кнопок создается модель (см. рис. № 2.4).
1 2 3 4 5
Рис.2.4. Часть панели форматирования с кнопками для создания модели.
Для отображения сущности необходимо нажать кнопку 1 (см. рис. № 2.4), указатель
курсора поменяет свой вид на крестик, что позволит, щелкнув мышью, показать местоположение
в рабочем окне сущности. В рабочем окне появится:
Сущность отображается прямоугольником, разделенным на две части. Над
прямоугольником выделено имя и номер сущности – Е/5 (сущность – Entity № 5). Выделение
говорит о том, что мы можем изменить имя сущности, просто набирая на клавиатуре нужное нам:
12
Обратите внимание - размер прямоугольника изменится таким образом, чтобы имя
сущности читалось целиком. Размер и положение сущности меняется привычным в Microsoft
Office способом работы с объектами. Если необходимо изменить имя сущности - щелкните
дважды по нему мышью, появится окно работы с сущностью – рис.2.5, и в строке Name можно
вписать другое имя.
Рис.2.5. Изменение имени в окне работы с сущностью.
Для того чтобы в вести атрибуты сущности, необходимо добавить эти атрибуты в окне
ввода нового атрибута окна работы с атрибутами - рис.2.6. При этом пишется имя атрибута и
выбирается один из четырех предлагаемых типов атрибута:
Blob – логический и OLE-тип,
Datetime – время-дата,
Number - числовой,
String – символьный тип.
Для работы с введенными атрибутами – изменения имени, уточнения типа, удаления
атрибута, а также для указания, является ли выбранный атрибут первичным ключом, значения
атрибута по умолчанию - открывается окно работы с атрибутами – рис. 2.7.
13
Рис.2.6. Добавление нового атрибута в окне ввода атрибута.
На рис. 2.7. показано назначение введенного атрибута «Табном» сущности «Персонал»
первичным ключом. При нажатии на кнопки, расположенные в нижней части окна, можно:
New… - открыть окно ввода нового атрибута;
Rename… - изменить имя выбранного атрибута;
Delete – удалить выбранный атрибут.
Для уточнения типа атрибута, для указания значения атрибута по умолчанию в правой
части окна работы с атрибутами выбирается вкладка Datatype. На рис. 2.8. показано, что для
атрибута FIO тип принимается как varchar (55) – не более 55 символов.
Необходимо отметить, что первичный ключ располагается в верхней части прямоугольника
(«на крыше»), все остальные атрибуты – в нижней. Можно указателем мыши переносить
атрибуты «с крыши» вниз и наоборот, меняя таким образом первичный ключ.
14
Рис.2.7. Окно работы с атрибутами.
После ввода всех атрибутов желательно изменить высоту прямоугольника таким образом,
чтобы были видны все атрибуты и оставалось место примерно еще для двух атрибутов – см. рис.
2.9.
У изображения сущности можно менять шрифт, его размер, цвет шрифта, цвет фона и
линий аналогично тому, как это делается в среде Microsoft Word.
Для установления связей между сущностями необходимо пользоваться кнопками 2-5 (см.
рис.2.4.).
Для выбора нужной связи необходимо использовать таблицу 2.2, подготовленную на этапе
концептуального проектирования.
Для отображения связей с показателями кардинальности 1хМ и 1х1 используют:
кнопку 4 – «идентифицирующая связь», она переводит первичный ключ сущности с
кардинальностью «1» в качестве обычного, внешнего атрибута в сущность с кардинальностью
«М»;
кнопку 5 – «неидентифицирующая связь», она переводит первичный ключ сущности с
кардинальностью «1» в качестве первичного, внешнего атрибута в сущность с кардинальностью
«М».
15
Рис. 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”, необходимо указать
конкретную цифру. В этом случае экземпляры сущности «Персонал» обязательно принимают
участие в связи и заключают конкретное количество договоров.
16
Рис. 2.10. Окно «Свойства связи» в CASE-средстве Erwin.
Если две сущности связаны друг с другом двумя или более разными связями, а также в
случае рекуррентных (ролевых) связей, необходимо указать ролевые имена, с которыми эти
сущности вступают в связь. Для этого в окне «Свойства связи» (Relationship Property) открывают
вкладку «Ролевые имена» (Rolename) (см. рис. 2.11) и в строке «Ролевое имя» (Rolename)
указывают имя – в данном примере для связи «доставляют» ролевое имя - «курьер». Ролевое имя
используется в качестве имени внешнего атрибута, по которому передается первичный ключ.
Для отображения связи «суперкласс-подкласс» используется кнопка 3. При этом сначала
щелкают мышью по кнопке 3 – выбирают тип связи, затем щелкают по сущности-суперклассу,
затем по сущности-подклассу. Если у сущности-суперкласса есть несколько сущностейподклассов, то для их включения используется кнопка 4, сначала щелкают по кнопке, затем – по
значку связи, а затем – по сущности-подклассу. Для связи «суперкласс-подкласс» необходимо
указать степень вхождения подклассов в суперкласс в окне “Subtype Relationships” (см. рис. 2.12),
вызываемое правой кнопкой мыши. “Complete” – сущность-суперкласс состоит только из
экземпляров сущностей-подклассов; “Incomplete” - сущность-суперкласс состоит не только из
экземпляров сущностей-подклассов. На рис. 2.12. изображен пример неполного вхождения
сущностей-подклассов в сущность-суперкласс: «Персонал» состоит не только из «Менеджеры» и
«Операторы».
17
Рис. 2.11. Вкладка “Ролевые имена” (“Rolename”).
При отображении полного вхождения значок связи будет иметь двойное подчеркивание.
Для отображе6ния связи с показателем кардинальности МхМ используется кнопка 5.
Передача ключа при этой связи не происходит (см. рис. 2.13).
При отображении всех сущностей и связей, заявленных в таблицах
2.1 и 2.2., получается ER- диаграмма в стандарте IDEF1X.
18
Рис. 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.
19
2.3. Этап физического проектирования.
Этап физического проектирования всегда тесно связан с особенностями конкретной
выбранной СУБД.
Рис. 2.12. Пример связи с показателем кардинальности МхМ.
2.3.1. Генерация базы данных.
На этапе физического проектирования в ER-диаграмме для всех атрибутов уточняются все
типы данных, чтобы убедиться в их применении в выбранной среде реализации. Для этого в
CASE-средстве Erwin достаточно выбрать физический этап проектирования в пиктографическом
меню (см. рис. 2.14). Все имеющиеся связи с показателем кардинальности «М х N» раскрываются
в ассоциативные таблицы. Чтобы получить ассоциативную таблицу, необходимо поставить курсор
на связь с показателем кардинальности «М х N»и нажать на правую кнопку мыши, выбрать из
всплывающего меню строчку ”Create Аssociative Table” и последовательно нажимать «OK» во
всех диалоговых окнах. Пример вида окончательной ER-диаграммы представлен на рис. 2.13.
20
Менеджеры
Договор
Таб_ном: int
НД: int
НомерКаб: int
Дата_закл: datetime
Ст_ть: int
курьер: int
НК: int
оператор: int
менеджер: int
Персонал
Таб_ном: int
Дата_рож: datetime
FIO: varchar(20)
мобтел: varchar(20)
адрес: varchar(20)
должность: varchar(20)
Договор_Объект
НО: int
НД: int
стоимость: money
Дата_нач: datetime
срок: int
Операторы
Таб_ном: int
%сделки: int
Телефон
Объект
Нп_п: char(18)
НО: int
Адрес: varchar(20)
Цена: int
Клиент
тип: varchar(20)
значение: varchar(20)
НК: int
НК: int
ФИО: varchar(20)
место_раб: varchar(20)
Рис. 2.13. Пример ER-диаграммы на этапе физического проектирования.
Для генерации таблиц и схемы данных в выбранной СУБД необходимо выполнить
следующие действия:
cоздать пустой файл базы данных;
выполнить команду “DataBase” – “DataBaseConnection” и в появившемся диалоговом окне в
строке “DataBase” выбрать полный путь к созданному пустому файлу;
выполнить команду “Tools” – “Forward Engineer” - «OK».
Рис. 2.14. Переход к физическому этапу проектирования.
3.Проектирование пользовательских интерфейсов.
Целью данного этапа является проектирование интерфейса пользователя и прикладных
программ, предназначенных для работы с базой данных в рамках его должностных инструкций.
Необходимо помнить, что в жизненном цикле информационных систем этот этап
выполняется параллельно с этапом проектирования базы данных с постоянным обменом
информации.
Необходимо убедиться, что все заявленные требования пользователей будут выполняться и
поддерживаться создаваемой базой данных.
3.1. Список требований пользователей.
21
На данном этапе необходимо зафиксировать всех пользователей будущей информационной
системы и выписать их функциональные требования в рамках заявленной к проектированию
функции. Пользователи, имеющие разные должностные инструкции, но выполняющие
одинаковые задачи (или разностью в выполнении задач можно пренебречь) по реализации
заявленной к проектированию функции, называются типом пользователя.
Функциональные требования типа пользователя необходимо проанализировать и записать
таким образом, чтобы они представляли специализацию транзакций. Транзакция – одно или
несколько неделимых действий над базой данных, выполняемых одним типом пользователей.
Например:
Менеджер:
Список всех операторов.
Перечень всех договоров конкретного менеджера за конкретный месяц.
Поиск информации об операторе по его ФИО.
Оператор:
Ввод нового договора.
Поиск объекта по цене.
Ввод нового клиента.
Поиск всех договоров конкретного клиента.
Список
типов пользователей, а тем более список транзакций для каждого типа
пользователя, должен соответствовать той функции или функциям, которые были заявлены для
проектирования информационной системы. Например, если заявлена функция продаж, возможны
следующие транзакции:
Продавец:
Поиск товара по названию и цене «от» - «до»
Поиск товара по марке-производителю.
Формирование чека.
Список всех своих чеков за период.
Невозможны в этом случае транзакции:
Продавец:
Ввод нового товара – относится к описанию функции поставок.
Список всех чеков по фамилии конкретного сотрудника - так как данная транзакция не
входит в перечень должностных инструкций продавца, а относится к деятельности менеджера
отдела продаж.
Для включения в специализацию транзакций при выполнении курсового проекта следует
избегать транзакций типа Delete (удаление) и типа Update (обновление).
3.2. Анализ транзакций на этапе логического проектирования.
Целью анализа транзакций является проверка того факта, что база данных, модель которой
получена на этапе логического проектирования поддерживает необходимыми данными все
заявленные транзакции пользователей.
Для этого мы используем модель данных, полученную на этапе логического
проектирования в результате анализа, и попытаемся выполнить каждую транзакцию вручную.
Если это окажется возможным для всех транзакций, заявленных в списке транзакций, то можно
считать, что данная логическая модель успешно проверена. Если же выполнить вручную
некоторую из транзакций окажется невозможно, значит
в логической модели данных
присутствует ошибка, которую необходимо удалить. Вероятнее всего, в модели отсутствуют
необходимая сущность, атрибут или связь.
Для примера рассмотрим анализ всех транзакций, заявленных менеджером.
Список всех операторов.
22
Для выполнения данной транзакции необходимо найти значение первичного ключа –
номера данного менеджера среди значений данного атрибута сущности «Менеджеры». Если такой
номер не будет найден, необходимо вывести сообщение о том, что такого менеджера не
существует. Если будет найден, далее необходимо найти связь с сущностью «Операторы». Такая
связь есть через сущность «Персонал», но эта связь не позволяет определить, кто из персонала
подчиняется данному менеджеру. Данную транзакцию выполнить нельзя. Необходимо добавить
связь «Менеджеры» - «управляют» - «Операторы», показатель кардинальности которой «1 х М». В
этом случае по этой связи мы найдем данные обо всех операторах в сущности «Операторы», у
которых значение атрибута “Таб_ном_мен” равен заявленному. Результат анализа данной
транзакции и все необходимые исправления модели данных приведены на рис. 3.1.
Перечень всех договоров конкретного менеджера за конкретный месяц.
Для выполнения данной транзакции необходимо найти значение первичного ключа –
номера данного менеджера в сущности «Персонал», далее найти значения всех атрибутов в
сущности «Договор», где значение атрибута “менеджер” совпадает с заданным и значение
атрибута “Дата_закл” попадает в границы заданного месяца. Данная транзакция может быть
выполнена. Результат анализа данной транзакции и все необходимые исправления модели данных
приведены на рис. 3.1.
Поиск информации об операторе по его ФИО.
Для выполнения данной транзакции необходимо найти заданное значение атрибута “FIO” в
сущности «Персонал». Если такого значения нет, необходимо вывести сообщение об ошибке, если
таких значений одно или больше, а это возможно, так как атрибут “FIO” не является первичным
ключом, и для всех этих значений необходимо найти значения первичных ключей «Таб_ном» и
всех остальных атрибутов, так как они содержат данные об искомых операторах, и далее найти
значения всех атрибутов в сущности-подклассе «Операторы», где значения первичных ключей
совпадают с найденными. Данная транзакция может быть выполнена. Результат анализа данной
транзакции и все необходимые исправления модели данных приведены на рис. 3.1.
В курсовой проект достаточно включить только визуальное отображение анализа не
более 15 транзакций, наиболее важных для заявленной к проектированию функции, то есть тех
транзакций, которые поддерживают работу пользовательского интерфейса (ПИ). Для этого
необходимо сначала выполнить проект макета ПИ.
Документация на пользовательские интерфейсы.
Для каждого заявленного типа пользователя приводится список основных должностных
инструкций. Далее создается макет ПИ для каждого типа пользователя, позволяющий в удобной и
понятной пользователю форме реализовать эти функции. В курсовой проект достаточно включить
пользовательский интерфейс только для одного типа пользователя, в рамки деятельности которого
входит реализация заданной к проектированию функции. ПИ должен позволять реализовывать все
должностные инструкции пользователя, и только их.
Рис. 3.1. Пример
проектирования.
визуального отображения анализа транзакций на этапе логического
23
В рамках курсового проекта разрабатывается диалоговый пользовательский интерфейс,
содержащий сценарий деятельности конкретного пользователя.
Документация на пользовательские интерфейсы содержит следующие разделы:
Постановка задачи.
При постановке задачи необходимо указать какой тип пользователя будет работать и какие
действия будет реализовывать в данном ПИ. Например:
ПИ обеспечивает деятельность оператора по заключению договора на аренду жилья:
Поиск или ввод клиента;
Поиск объектов жилья по требованию клиента:
По ближайшей станции метро и/или цене «от»-«до»;
По количеству комнат и/или метражу жилой площади;
По наличию телефона и/или мебели;
Оформление договора.
Исходные данные.
Исходные для ПИ данные делятся на:
Переданные из БД.
Обычно в ПИ оформляются как поля ввода (текстовые поля). Необходимо перечислить все
поля ПИ, которые содержат данные из БД и указать из какой таблицы (поле) они берутся.
Например:
Поле «Полный адрес объекта» берется из таблицы Объект(Адрес)
Поля ФИО, дата рождения, прописка клиента – таблица Клиент(ФИО, Д_рож, адрес)
Поля Паспортные данные – таблица Паспорт(номер, серия, кто, когда)
Поле Стоимость – таблица Объект(ст-ть)
Количество месяцев.
Введенные вручную.
Обычно в ПИ оформляются как поля ввода (текстовые поля). Необходимо перечислить все
поля ПИ, которые вводятся вручную. Например:
ФИО клиента
Номер и серия паспорта
Цена «от»
24
Цена «до»
Начало аренды
Конец аренды.
Справочные константы.
Обычно в ПИ оформляются как метки, поля ввода (текстовые поля) с уже введенными
данными, поля со списком выбора, метки с «переключателем». Необходимо перечислить все поля
ПИ, которые содержат справочную информацию и ее источник. Например:
ближайшая станция метро – список всех станций метрополитена.
3.3.3. Алгоритм решения.
Если в ПИ проводятся какие-либо вычисления, необходимо пояснить их алгоритм либо в
виде формул, либо в виде блок-схемы, либо в виде текста с пояснениями. Например:
стоимость по договору = стоимость * количество месяцев
количество месяцев = конец аренды – начало аренды.
Необходимо заметить, что в правой части формулы должны содержаться только данные из
пункта 3.3.2, в противном случае их необходимо пояснить следующей формулой.
3.3.4. Макет интерфейса.
Если ПИ имеет только одну экранную форму – представлять нужно только ее, если
несколько – представлять нужно все формы с указанием условий переходов и возвратов от одной
формы к другой. Например:
Рис. 3.2. Макет пользовательского интерфейса.
25
3.3.5. Перечень всех управляющих элементов макета.
Необходимо перечислить все управляющие элементы, которые используются в макете ПИ
и зафиксировать действия, которые будут выполняться при использовании этих элементов.
Удобнее всего это сделать в табличной форме. Например:
Таблица №3.1 Описание управляющих элементов.
Номер
Имя элемента
Какие действия выполняются
управляющего
элемента
ComboBox1
Позиционирование конкретного оператора
Buttom1
Найти
Поиск данных о клиенте по номеру и серии
паспорта
Buttom2
Добавить клиента
Добавление данных о новом клиенте
Buttom3
Просмотреть
список Просмотр всех договоров найденного
договоров клиента
клиента
ComboBox2
Выбор станции метро из всего списка
станций
ComboBox3
Выбор количества комнат из возможного в
26
ComboBox4
Buttom4
Найти
ComboBox5
Buttom5
Заключить договор
Buttom6
Распечатать договор
компании списка (1,2,3,4)
Выбор типа дома из возможного в компании
списка.
Поиск варианта квартиры по одному или
любому набору представленных параметров.
Выбор месяца
Добавление данных нового договора. В
результате добавления в окне «Номер
договора»
автоматически
появится
следующий номер договора.
В окне «Количество договоров за день»
происходит увеличение на 1.
В окне «на сумму» происходит увеличение
на сумму добавленного договора.
Происходит распечатка шаблона договора,
хранящегося в MSWord с добавлениями
полей таблицы «Договор»
Программный код.
Макет ПИ реализуется на любом объектно-ориентированном языке программирования.
Программный продукт сохраняется на любом носителе, который прилагается к пояснительной
записке. В пояснительной записке указывается имя файла, где записан программный код.
Распечатка программного кода реализации ПИ на любом объектно-ориентированном языке
программирования добавляется к документации.
В рамках работы над курсовым проектом полная реализация ПИ не является обязательным
этапом и оговаривается преподавателем. Возможна либо частичная реализация, либо полное
отсутствие реализации.
Реализация транзакций средствами выбранной СУБД.
В специализацию транзакций необходимо добавить все транзакции, поддерживающие ПИ,
если они еще не включены. Часть этих транзакций можно реализовать внутренними средствами
СУБД.
В курсовой проект включаются 10 реализованных средствами СУБД транзакций.
Описание реализованных транзакций делается в виде таблицы (см. таблицу №3.2)
Таблица №3.2. Описание реализованных в СУБД MS Access транзакций.
Имя
или
номер
транзакции
по
спецификации транзакции
Т12. Выбор сотрудников с должностью
оператор
Т27. Список договоров, содержащий
информацию об арендованных объектах
Форма реализации
Запрос
Имя реализации.
Операторы
Сохраняемый запрос
Список_договоров
В первой колонке не обязательно указывать саму транзакцию, как приведено в таблице.
Достаточно указать ее номер по спецификации.
Анализ транзакций на этапе физического проектирования.
Целью анализа является определение функциональных характеристик транзакций, которые
будут выполняться в базе данных, и выделение наиболее важных из них.
Для того чтобы разрабатываемый физический проект базы данных обладал требуемым
уровнем эффективности, необходимо получить максимум сведений о тех транзакциях, которые
27
будут выполняться в проектируемой базе данных. Нам потребуются как качественные, так и
количественные характеристики. Для каждой транзакции необходимо знать следующее:
ожидаемая частота выполнения транзакций;
отношения и атрибуты, к которым потребуется иметь доступ при выполнении транзакции, а
также тип этого доступа ( R – выборка, I – вставка, U – обновление, D – удаление );
ограничения, устанавливаемые на время выполнения транзакций.
Во многих случаях проанализировать все транзакции просто невозможно, поэтому
необходимо выбрать из них самые «важные». В схеме, на которой проводился анализ транзакций
на этапе логического проектирования (см. рис. 3.1), надо установить, какие из отношений
наиболее интенсивно используются при выполнении транзакций. Для этого необходимо посчитать
количество входящих в каждую сущность стрелочек. Например, в нашем случае получается
следующее:
Сущности
Персонал
Менеджеры
Операторы
Договор
Количество входящих
стрелочек
3
1
2
1
Так как в нашем примере анализировалось небольшое количество транзакций, то
количество входящих стрелочек для всех сущностей примерно одинаково. Обычно 2-3 сущности
имеют значительно большее количество, чем все остальные. На этапе физического
проектирования целесообразно анализировать только те транзакции, которые включают
обращения к отношениям с большим количеством входящих стрелочек. В нашем случае это
сущности «Персонал» и «Операторы», через которые проходят все заявленные в нашем примере
транзакции. Обычно остается для анализа на физическом этапе проектирования около 80% всех
транзакций.
Далее необходимо указать ожидаемое количество строк в отношениях, а также среднюю и
максимальную кратности каждой связи (см. рис. №3.3). Например, ожидается, что персонал
компании составит 50 человек, 4 из которых менеджеры, 40 операторов. Компания владеет 500
объектами жилья, на которые заключается 1000 договоров.
Рис. № 3.3. Указание ожидаемой размерности отношений и связи.
28
При анализе каждой из транзакций очень важно знать не только среднее и максимальное
количество ее вызовов в час, но и иметь сведения о тех днях недели и часах суток, когда она
обычно выполняется, включая и данные о времени пиковой нагрузки. Например, частота вызова
некоторых транзакций может удерживаться на некотором уровне постоянно, но все же она имеет
четко выраженный пик нагрузки в последний четверг месяца с 14-00 до 16-00, вызванный
подготовкой отчетов. Другие транзакции вообще могут выполняться только в определенные
моменты времени, например - по понедельникам с 9-00 до 10-00, что также является пиком
нагрузки.
Когда выполнение потока транзакций требует частого доступа к определенным
отношениям, очень большое значение приобретают выбранные для них схемы выполнения. Если
выполнение этих транзакций не зависит друг от друга, риск возникновения проблем с
производительностью уменьшается. Однако если схемы их выполнения конфликтуют, возможные
проблемы могут быть частично устранены посредством тщательного изучения транзакций, что
позволит найти способ их модификации с целью повышения их производительности. В нашем
случае необходимо рассмотреть транзакции, проходящие через оператора и персонал. Результат
анализа заносят в таблицу 3.3.
Таблица № 3.3. Результаты анализа.
Тран
закция
Т1. Список всех
операторов
От отношения
Актив-ность
День недели
Время суток
Пиковая
Средняя
К отношению
Понедельник
Атрибуты
9-00 – 12-00
Тип доступа
Менеджер
Менеджер
Оператор
Таб-ном
Таб-ном-мен
Таб-ном
R(E)
R(E)*
Оператор
Персонал
Таб-ном
R(E)
Частота
месяц
1
Частота
месяц
1
10 - 15
вызовов
в
вызовов
в
29
*
R
Тран
закция
Т2. Перечень всех
договоров
конкретного
менеджера
за
конкретный месяц.
От отношения
Актив-ность
День недели
Время суток
Частота
месяц
вызовов
в
Пиковая
9-00 – 12-00
4
Средняя
Последний четверг
месяца
-
-
-
К отношению
Атрибуты
Тип доступа
в
Персонал
Договор
Таб-ном
Таб-ном
*
R(E)
R(E)*
R
Частота вызовов
месяц
4
800 - 1200
Персонал
в
Актив-ность
День недели
Время суток
Частота
месяц
вызовов
Тран
закция
Т3.
Поиск
информации
об
операторе по его
ФИО
От отношения
Пиковая
Последний четверг
месяца
Понедельникпятница
Атрибуты
15-00 - 16-00
40
Случайным
образом
Тип доступа
20
вызовов
в
-
Персонал
FIO
*
R(E)
R
Средняя
К отношению
Частота
месяц
60
Заключение.
В заключении к курсовому проекту необходимо в краткой форме подвести выводы по
проделанной работе, которые могут включать:
Мнение студента о проделанной работе;
Отношение к изученному материалу;
Оценку средств и методов проектирования.
30
ПРИЛОЖЕНИЕ 1
Темы и объекты курсовых работ
1. Продать авиабилет
Объекты: авиакомпании, аэропорты, типы самолетов (мест), экземпляры самолетов,
расписание, пассажиры (ф.и.о, паспорт, № билета), цены.
2. Продать железнодорожный билет
Железные дороги, станции, расписание, цены, маршруты (поезд №), экземпляры поездов,
типы вагонов, экземпляры вагонов, проданные билеты
3. Лекарственные растения
Название растения (русский, латынь), лекарственные сборы, заболевания, лекарственные
формы (отвары, настои, порошки:), способ применения.
4. Склад
Некоторая фирма имеет склады (№ склада, адрес), на складе работают кладовщики, которые
принимают и отпускают товары. Товары поступают на склад по накладным (№, дата, от
кого), в накладной для каждого товара указано количество и цена. Товары могут также
поступать и от собственных подразделений производства, которые эти товары производят. В
этом случае они также сопровождаются накладной. Товары продаются фирмой внешним
организациям по цене назначаемой фирмой. Цены продажи в каждый данный момент
фиксированы и отражаются в прейскуранте (price list). Товары также передаются по
накладной собственным подразделениям для использования в процессе производства.
5. Квартплата
Домовладельцы, дома, коммунальные услуги (холодная вода, горячая вода, газ,
электроплиты). Коммунальные услуги имеют цену, которая исчисляется либо по числу
жильцов, либо по квадратным метрам общей площади. Поставщики услуг. Клиенты
(жильцы) проживают в квартирах. Клиенты вносят плату за жилье и услуги.
6. Метрологическая служба предприятия
Предприятие имеет ряд подразделений, в которых используются измерительные
приборы. Метрологическая служба следит за состоянием приборов. Прибор имеет вид
(амперметр) и тип (конкретное наименование модели (Е-12U6)). Для типа прибора
определена периодичность поверки (1 раз в 6 месяцев). Для каждого экземпляра прибора
хранится дата последней поверки. Прибор имеет конкретного производителя и гарантийный
срок, назначенный производителем для этого типа. Существует некоторое множество
характеристик приборов (ток, напряжение, размеры :). Для каждой характеристики
существует множество возможных значений. Тип прибора может обладать некоторой
характеристикой, имеющей для него определенное значение (ток 5 ампер).
7. Учет работ бригады программистов
Бригада программистов выполняет работы по разработке, сопровождению, продаже,
установке программного обеспечения (ПО) и обучению персонала заказчика работе с ПО.
Каждый член бригады ежедневно ведет учет своего рабочего времени. Фиксируется
заказчик, конкретное ПО, вид работы, раздел ПО. Части разработанных программ находятся
в файлах, каждый из них имеет автора и содержит ряд функций, вызываемых из других
функций и вызывающий другие функции.
8. Автосервис
Предприятие автосервиса располагает цехами, в цехах работают мастера, каждый из
которых выполняет некоторое работу некоторого вида (малярные, электротехнические:).
Клиент сдает машину в ремонт, при этом оформляется заказ, содержащий некоторый
перечень работ. Работа относится к некоторому виду и для своего выполнения требует
определенного количества материалов и комплектующих изделий. Имеются расценки на
материалы и комплектующие. Конкретная работа из заказа выполняется мастером.9.
Междугородние автобусные перевозки
31
Задана география автомобильных дорог. Некоторое множество АТП имеет парки
автобусов. Подлежит исполнению множество рейсов, имеющих определенную регулярность.
Рейс передвигается по дорогам, делая остановки в пунктах. Известны цены и время
перемещения марки автобуса между пунктами. Автобусы ведут водители. Продажа билетов
фиксируется в БД.
9. Диспетчер троллейбусного парка
Троллейбусный парк располагает некоторым множеством машин (троллейбусов),
имеющих номер и дату производства. Каждая машина может находиться в состоянии:
работа, неисправность, капитальный ремонт, производимый с некоторой периодичностью.
Парк обслуживает некоторое множество маршрутов. Маршрут имеет время прохождения.
Водители водят машины и имеют категорию. Работа водителя определенной категории
оплачивается по некоторому тарифу. Парк работает в три смены. Функции диспетчера
заключаются в назначении машин и водителей для выполнения маршрута. Планирование
ведется на неделю вперед. Хранится некоторая история выполненных работ, которую
использует бухгалтерия для начисления зарплаты.
10. Учебный процесс в школе
Программа для завуча имеющая целью распределение нагрузки и составление
расписания для выполнения учебного плана.
11. Агентство Кука
Некоторая фирма зарабатывает тем, что обеспечивает путешественников или просто
тех, кому надо куда либо съездить билетами на транспорт и местами в гостиницах. Заказчик
(№ заказа, дата заказа, Ф.И.О., телефон), явившись в агентство описывает свой маршрут и, в
конце концов получит некоторое множество билетов и бронь в соответствующих
гостиницах.
12. Оптовый продовольственный рынок
Отрасли промышленности
Предприятия - производители могут быть отнесены к некоторой отрасли, например,
пищевая промышленность, перерабатывающая промышленность, нефтеперерабатывающая:
Для отрасли задается:
код отрасли (краткое название или аббревиатура)
наименование отрасли
Административное деление
Административное деление отображается в виде иерархии
Республика - Область - район - Населенный пункт
Товары
Классификация товаров в общем случае является многоуровневой иерархической. На
нижнем уровне иерархии находятся собственно товары. Для каждого товара или группы,
находящейся на произвольном уровне задается:код родительской группы
собственный код, который будет являться родительским для нижележащих уровней
иерархии
наименование группы или товара
признак того, что данная запись является описанием товара или описанием уровня
классификации
единица измерения (перечислимый домен)
Такой подход пригоден для построения любой иерархической классификации. Его
использование позволит получать в дальнейшем сводные документы по любым уровням
классификации.
Предприятия
Под предприятиями мы понимаем любые организации и частных предпринимателей,
осуществляющими оптовую покупку и продажу товаров.
32
Предприятие имеет атрибуты:
код отрасли
код населенного пункта
собственный код предприятия
тип предприятия (производитель, посредник, покупатель, акционер)
полное название предприятия
Данные о продаваемых и покупаемых товарах хранятся раздельно.
Для каждого товара задается:
код товара по классификации
размер партии
(альтернатива - мощность производства ?)
цена за единицу
Торговые площадки
Одним из основных ресурсов ОПРЧО являются торговые площадки, на которых
производятся торги.
Для торговой площадки задается:
код торговой площадки
полное название
Торговые площадки делятся на секции по группам товаров:
1. Рыба и морепродукты
2. Фрукты и овощи
3. Птицеводческие продукты
4. Мясные продукты
5. Поливалентная
6. Цветы
Каждая секция в свою очередь содержит некоторое количество торговых мест. Торговые
места сдаются в аренду предприятиям - продавцам.
Для каждого торгового места задано:
- код площадки
- код секции
- номер торгового места (уникальный в пределах площадки)
Факт аренды отражается в БД в виде записей:
код площадки
номер торгового места
код предприятия - арендатора
дата начала срока аренды
дата окончания срока аренды
стоимость аренды (возможно, ссылка на договор)Торги
Оптовыми торгами являются торги, публично проводимые в торговом зале.
Торг идентифицируется полями:
код площадки
дата торгов
Результатом торгов являются сделки:
условный номер сделки
код площадки
код предприятия - продавца
код предприятия - покупателя
Для каждого товара в сделке:
код товара по классификации
количество
33
цена
13. Журнал "Пульс цен"
Фирмы торгуют компьютерами и комплектующими. Комплектующие (материнская
плата, процессор) имеют цену, назначенную фирмой. Существуют стандартные
конфигурации компьютеров, предлагаемые фирмами, состав которых предопределен.
Комплектующие имеют производителя и характеристики. Характеристики способны
принимать значения.
14. Кафедра
Кафедра выпускает ряд специальностей. На кафедре работают преподаватели и
вспомогательный персонал. Студенческие группы относятся к специальности.
Преподаватели читают курсы и выполняют другие виды нагрузки. Учебные планы
специальности предусматривают определенное число часов по виду занятия для курса в
семестре. Группы могут объединяться в потоки. Студенты сдают экзамены, зачеты и
курсовые работы. Цель программы - распределение нагрузки по преподавателям.
15. Лесное хозяйство
Лесничество обслуживает леса. Леса задаются на карте в виде замкнутых ломаных линий.
Лес имеет породный состав. Лесная порода может быть отнесена к одной из двух групп:
дерево / кустарник. Обслуживание есть выполнение некоторых запланированных
мероприятий (прополка, посадка, прореживание, опашка). Для выполнения мероприятия над
единицей площади требуется техника, рабочие и горюче - смазочные материалы (ГСМ).
Техника подразделяется на группы, каждое наименование единицы техники имеет марку.
Работник имеет специальность, разряд и получает почасовую оплату.
16. Строительные ремонтные работы
Организация выполняет строительные ремонтные работы по договорам (№ договора,
дата договора). Работы выполняются над объектами (код, название, адрес). Работы
подразделяются на виды (каменные, земляные, малярные), имеют единицу измерения и
тариф на выполнение единицы работы. В рамках договора выполняется некоторое
количество некоторых видов работ. Для выполнения работ необходимы рабочие
(специальность, разряд, тарифная ставка); техника (группа, марка); материалы (код,
название, единица измерения, цена). По мере выполнения работ закрываются акты приемки сдачи выполненных работ. На основании акта формируется счет на оплату работ, который
предъявляется заказчику, и который его оплачивает платежным поручением через свой банк.
17. Железнодорожные грузовые перевозки
Железная дорога имеет с организациями договоры на перевозку грузов. Груз
сопровождается накладной (номер, дата, организация). В накладной перечислены грузы и их
количество. Товары, перевозимые по накладной, едут в одном вагоне. Вагон имеет номер,
емкость и вид (платформа, цистерна). Груз отправляется одной организацией и будет получен
другой (возможно той же самой). Груз едет от пункта отправления до пункта
назначения. Вагон прицепляется к поезду, имеющему маршрут, номер и дату. В процессе
движения он может быть перецеплен к другому поезду.
18. Конный спорт (по Дику Френсису)
Лошади и их родословные, жокеи, владельцы лошадей (лошадь может быть продана),
тренеры, конюшни, принадлежащие владельцам, состязания, их виды, ставки в тотализаторе
(выплата 1:20).
19. Отдел кадров
Предприятие имеет определенную номенклатуру должностей (код, наименование,
тариф). Предприятие делится на подразделения, подразделения на отделы. Каждое
подразделение или отдел имеют руководителя. Каждое подразделение или отдел имеют
штатное расписание. Должности по штатному расписанию занимают сотрудники. Сотрудник
имеет атрибуты (Ф.И.О., год рождения). Сотрудник имеет послужной список. Сотрудник
34
имеет поощрения и взыскания. Сотрудник имеет некоторую историю получения образования
и повышения квалификации.
20. Частный предприниматель
Частный предприниматель - программист выполняет договорные работы на
разработку и сопровождение программного обеспечения. Его заказчиками являются
организации. Договоры разбиваются на этапы, каждый этап имеет цену. Для выполнения
работ необходимы затраты на комплектующие компьютера, программное обеспечение,
литературу: Если объем договора слишком велик, то предприниматель заключает договоры
субподряда со своими коллегами. Все расчеты по договорам выполняются платежными
поручениями через банки ЧП и заказчиков (или субподрядчиков).
21. Туризм
Фирма специализируется по организации спортивных водных туристических походов
по рекам России. Существует множество маршрутов. Маршруты имеют категории
сложности. Маршрут может представлять собой несколько отрезков перемещения (начало,
конец, расстояние, способ перемещения - пеший или сплав, дней). На участках сплава
имеются пороги, имеющие собственные имена. Пороги классифицируются по сложности.
Фирма располагает штатом инструкторов, аттестованных на проведение походов заданной
категории сложности. Инструкторы оплачиваются по тарифной ставке (за день).
Фирма располагает снаряжением, относящимся к некоторой группе (палатки, плоты,
катамараны, спальные мешки). Каждое изделие группы относится к типу. Тип - множество
одинаковых изделий. Тип имеет цену и ресурс, выражаемый в числе походов. Изделие типа
имеет инвентарный номер.
Фирма набирает группу туристов, которые оплачивают услуги фирмы (экземпляр похода).
Стоимость похода складывается из затрат на дорогу, питание, амортизацию снаряжения,
оплаты инструкторов + фиксированный процент на доход фирмы.25. Охотничье хозяйство
Охотничье хозяйство разбито на участки. На участках водится живность разных
видов в определенном количестве на квадратный километр. Участок может быть сдан для
охоты группе охотников на некоторый отрезок времени. В лицензии для группы
указывается, какое количество и какого зверя они имеют право добыть (цена за единицу
вида).
Для поддержания количества зверья его надо подкармливать. Подкормка стоит
известное количество рублей на единицу вида в течение года.
Охотничье хозяйство располагает штатом сотрудников, занимающихся подкормкой и
другими видами работ (расчистка троп, ремонт охотничьих избушек). Рабочие имеют
специальность и тарифную ставку. Ежегодно составляется план работ.
22. Регистрация автотранспорта в ГИБДД
Фамилия, имя, отчество, адрес и т.д. владельца, марка, цвет, год выпуска, номер ПТС, и т.д.
автомобиля,
гос. номера дата постановки на учет, район, дата снятия с учета.
Поиск данных по автомобилю (марка, цвет, гос.номер, возможно частично) и владельцу на
заданный период.
23. Приемная комиссия ВУЗа
Абитуриенты, экзаменаторы, предметы, оценки; справочные сведения о подразделениях
учебного заведения.
Отчет: списки поступивших в ВУЗ, средний бал поступивших по подразделениям и по
предметам
24. Ветеринарная больница
Информация по больным-животным, информация по врачам, диагноз, назначенное лечение,
длительность, назначенные лекарственные препараты, стоимость лечения.
Отчет по врачам, по животным, по заболеваемости
35
25. Риэлтерское агентство
Код организации-застройщика, наименование организации, адрес организации, директор
организации, телефон организации, предложение квартир: код города и наименование, код
области и наименование, этажность, этаж, число комнат, площадь, др. информация,
стоимость, данные покупателя, номер договора, дата заключения, дата окончания
строительства,.
Отчет по наличию недвижимости для продажи, ее стоимости, подбор по заданным
параметрам, итоговые сведения продаж по городам, квартирам, стоимости.
26. Учет материальных запасов на предприятии
Код, наименование запаса, информация по организациям-поставщикам (код, наименование,
адрес, контактная информация, банковские реквизиты), минимальный запас, поступление,
выдача.
Отчет по поступлению и выдаче по типам товаров, отчет по материалам, для которых запас
меньше минимального с рекомендуемыми поставщиками.
27. Обмен валюты
Код, наименование, курсы валют, продажа, покупка, наличие валюты.
Отчет по типам валют с итогами покупок и продаж (число и курсовая стоимость проданных
валют)
28. Страховая компания
Вид страхования, страховой период, цена, информация по застрахованному лицу, дата,
номер договора, наступление страхового случая, учет платежей по страховому договору
Отчет по видам страховки с итогами (стоимость, частоты страховых случаев), отчет по
платежам по страховым случаям. 33. Учет успеваемости школьников
Код предмета и наименование, дата, оценка, класс, фамилия.
Отчет по предметам и классам со средней оценкой по школьникам и предметам, перевод в
следующий класс или оставшихся на второй год
29. Расписание занятий
Предмет, тип аудитории, форма работы (лабораторная, семинар, лекция), преподаватель,
группа, аудитория, день недели, время и т.д
Отчет по преподавателю, по дням недели, по группам.
30. Кинотеатр
Информация по фильму (название, режиссер, продолжительность…), наличие и продажа
билетов, план зрительного зала
Отчет наличие билетов на данный фильм, дата, время показа фильмов, доход по фильму, по
дате.
31. Продажа авиабилетов
Номер рейса, пункт отбытия, назначения, промежуточные пункты, время прилета, отлета из
пунктов, дни (даты) выполнения рейса, марка самолета, число мест, продажа: дата,
покупатель (паспортные данные), цена, рейс…
Отчет: наличие билетов на заданный рейс, направление, списки пассажиров по рейсам,
средняя загруженность самолетов по направлениям, по временам года
32. Учет кредитов в банке
Код организации, наименование организации, адрес организации, директор организации,
телефон организации, код города и наименование, код области и наименование, номер
договора, дата заключения, дата окончания, сумма, процент, сумма возврата, возвращенная
сумма, особые условия, процент штрафа за каждый просроченный день.
Отчет по дням возврата и городам с итоговыми суммами возвратов по дням возврата и
городам.
33. Учет поставок товаров
Поставки товаров: код поставщика, наименование, адрес, телефон, код города, наименование
36
города, код товара, наименование товара, количество, цена, единица измерения, дата
поставки.
Отчет по городам и поставщикам с итоговой стоимостью поставленных товаров по городам
и поставщикам.
34. Ювелирный магазин
Учет наличия и продажи товаров: код, тип, наименование ювелирного изделия, стоимость
приобретения, продажи, скидка, стоимость проданного товара, дата продажи
Отчет по типам изделий с итогами (стоимость приобретения, продажи, прибыль проданного
изделия) по поставщикам и видам изделий.
35. Магазин DVD-фильмов
Поступление и продажа дисков, типы и справки в зависимости от типов, поставщики,
продажа, цена…
Отчет: наличие дисков по типам, итоговые сведения объемов продаж по типам, по датам
36. Жилищно-эксплуатационная контора
Работники: ФИО, должность, квалификация, Учет заказов, тип заказа, ответственные за
исполнение заказа, дата поступления, выполнения заказа.
Отчет выполненные заказы по типам, объемы выполненных работ по сотрудникам
(затраченное время)
37. Платежная система
Через банкоматы Организации-получатели платежей, Плательщики, начисление сумм платежей,
учет
задолженности по платежам, начисление штрафов за просрочку платежей, учет поступления
платежей.
Отчет задолженности Плательщиков по видам платежей, поступление платежей по организациям
и периодам времени
38. Грузоперевозки
Пункт отправления, назначения, расстояние, транспорт, водитель, отправитель, даты
отправки, получения, вес.
Отчет: невыполненные перевозки, объемы перевозок между городами, число рейсов и число
дней работы водителя за указанный период
39. Учет движения маршрутного такси
Код типа транспорта, наименование типа транспорта, номер и длина маршрута, табельный
номер водителя, фамилия, дата выхода, код и наименование организации.
Отчет по видам транспорта и водителям с итогами (длина пройденного расстояния) по видам
транспорта и водителям, число рабочих дней по водителям.
40. Химчистка
Стоимость услуг, Поступление заказов (Заказчик, дата заказа, тип чистки, стоимость),
исполнитель заказа, дата исполнения.
Отчет: Объемы заказов и доходы по типам услуг, по исполнителям
41. Стоматологический кабинет
Прейскурант стоимости услуг, Врачи и Пациенты, диагноз, дата приема, предоставленные
услуги, стоимость, дата, время назначения на прием к врачу, формирование графика приемов
врачами.
Отчет: Наличие свободного времени у врача, отчет по загруженности врачей, по доходам,
получаемым врачами и в целом по организации.
42. Учет платежей за электроэнергию
Учет плательщиков (район, льготы), показания счетчика, начисление платежа, стоимость
электроэнергии, учет оплаты, задолженность или переплата.
Отчет по расходу электроэнергии и оплате по районам, списки должников на заданную дату
и сумма задолженности
37
43. Магазин программного обеспечения
Поступление и продажа программного обеспечения (Soft), типы и справки в зависимости от
типов, поставщики, продажа, цена…
Отчет: наличие Soft по типам, производителям, названиям, итоговые сведения объемов
продаж по типам, названиям, по датам.
44. Магазин бытовой техники
Код и наименование товара, скидки, данные поставщика, поступление товара, дата продажи,
наименование товара, количество, цена, скидка, сумма. Отчет по проданным товарам с
итоговыми суммами количества, сумм продаж и скидок, наличие товара по типу,
наименованию
45. Мебельная фабрика
Код и наименование продукции, нормы расхода материалов на производство данной
продукции, приход, расход материалов, учет выпуска продукции.
Отчет: наличие материалов и возможность выпуска продукции из этих материалов на
заданную дату, объемы выпущенной продукции по кварталам, потребность в приобретении
материалов для выпуска данной продукции
46. Учет семейного бюджета
Бюджет: дата, учетный номер члена семьи, фамилия, родство, код статьи расхода,
наименование статьи расхода, сумма расхода, код статьи дохода, наименование статьи
дохода, сумма дохода.
Отчет: по статьям расходов, членам семьи с итогами расходов по статьям и по членам семьи,
графики изменения доходов и расходов по кварталам, процент статьи расходов в семейном
бюджете.
47. Организация работы интернет-кафе
Прейскурант цен на услуги, число мест, оплата и предоставление услуг (по времени),
персонал, клиенты.
Отчет по типам услуг с итогами (стоимость, время) по клиентам (время, суммы оплаты).
48. Аренда спортивного зала, комплекса
Расписание занятий, арендатор, номер и сроки договора, требуемое оборудование, цена
аренды для арендатора и т.п.
Отчет: наличие незанятого времени зала, доход от аренды за заданный период, списки
арендаторов и т.п.
49. Жилфонд микрорайона
Улицы, дома, квартиры, их состояние, населенность, возраст населения и т.п.
Отчет: число жителей района, число домов, средний возраст жителей, потребность в транспорте,
школах, детских садах (по нормам на 1000 жителей).
38
Приложение 2.
Пример оформления пояснительной записки к курсовому проекту.
КАБАРДИНО-БАЛКАРСКИЙ ИНСТИТУТ БИЗНЕСА
Пояснительная записка к курсовому проекту
по дисциплине
«БАЗЫ ДАННЫХ»
на тему
«Проектирование базы данных для автосервиса»
Выполнил студент: Иванов Д.И., гр. КБ11/Д/Б/П/0/
Проверил:
Нальчик 2012
к.т.н., доц. Исмоилов М.И.
39
Введение
Трудно представить на сегодняшний день область человеческой деятельности, где бы
применение информационных систем представлялось неактуальным, значительно не упрощало и
улучшало деятельность человека.
В качестве объекта для проектирования информационной системы я выбрал автосервис.
Основной вид деятельности – предоставление физическим лицам услуг по ремонту отечественных
и импортных автомобилей. Информационная система, которую я буду проектировать, будет
обеспечивать данными эту основную функцию.
На мой взгляд, ремонт автомобилей – это очень распространенная на сегодняшний день
деятельность, требующая большого количества данных и как нельзя лучше подходящая для
примера проектирования информационной системы.
Задачи проекта
Исследование и описание предметной области.
Применение метода ER-диаграмм для разработки базы данных.
Использование CASE – средства Erwin для анализа модели и автоматической генерации БД.
Создание макета сценарного интерфейса для пользователя.
1. Описание предметной области.
Объект: автосервис
Функция: предоставления ремонтных услуг
У нас выполняются услуги:

замена расходных материалов (масло, колодок, фильтров)

тонировка

установка ксенона

установка сигнализации
Замена масла, фильтров, колодок , ксенона, тонировка, сигнализации осуществляются
только теми материалами, которые есть в автосервисе, клиент не может привезти свои расходные
материалы.
Имеются автомасла, фильтры, колодки таких известных отечественных и зарубежных
производителей, как Luxoil (Люксойл), Oil Right, Лукойл, ТНК, Spectrol (Спектрол), BP, Shell
(Шелл), Mobil (Мобил), Mannol (Маннол), Zic (Зик), Esso (Эссо), Castrol (Кастрол), вся замена
происходит в течении двух часов.
Тонировать стекло автомобиля можно только все сразу, нельзя за тонировать одно стекло,
т.к будет различие в оттенке пленки. Стоимость тонировки составляет 5000 рублей. Работа
осуществляется в течении одного рабочего дня.
Стоимость материалов суммируется со стоимостью работы, которая составляет 500
рублей.
Услуги в автосервисе выполняются мастером - универсалом и любой мастер может
выполнить любую услугу, которая осуществляется в нашем автосервисе.
Клиент, приехавший в автосервис, выбирает нужную ему услугу, из имеющегося у нас в
автосервисе перечня. Мастер выписывает клиенту накладную. На каждую услугу выписывается
отдельная накладная.
2.
Проектирование базы данных
40
2.1. Этап концептуального проектирования
2.1.1. Описание сущностей.
Выделение сущностей.
Услуги
С
Расходные материалы
Клиент
Работа (накладная)
Мастер
С
С
С
С
Сущность
Мастер
Атрибут
ID_мастера
ФИО
Телефон
Должность
Стаж
ID_клиента
ФИО
Телефон
Пол
Дата рождения
ID_услуги
Название
Клиент
Услуги
Накладная
Авто
Материалы
Тип
Время
выполнения
Стоимость
ID_документа
Дата
Сумма
ID_Авто
Год выпуска
Марка
Модель
Рег.Номер
ID_материала
Название
Количество
Стоимость
Производитель
Ключ
ПК
ПК
ПК
ПК
ПК
ПК
Домен
Тип
числовой
текстовый
числовой
текстовый
текстовый
числовой
текстовый
числовой
текстовый
числовой
числовой
текстовый
Примечание
Размер
50
50
50
50
50
50
100
50
50
50
50
50
текстовый
60
числовой
числовой
числовой
числовой
числовой
числовой
числовой
текстовый
текстовый
числовой
текстовый
текстовый
Числовой
числовой
Текстовый
30
50
100
30
30
100
50
50
30
30
50
50
50
50
50
замена масла/фильтров/колодок,
сигнализация, тонировка
иномарка; отечественный
зарубежный/отечественный
2.1.2. Описание связей.
Сущность1
Связь
Сущность2
Показатель
41
Мастер
Клиент
Услуга
Накладная
Авто
Принимают
Выполняет
Выписывает
Ремонтирует
Использует
Заказывает
Получает
Принадлежит
Заказывает
Требует
Включается
Применяются
Используют
Выдается
Указываются
Используются
Клиент
Услуги
Накладная
Авто
Материалы
Услуги
Накладная
Авто
Материалы
Услугу
Накладная
Авто
Материалы
Авто
Материалы
Материалы
кардинальности
М:М
1:М
1:М
1:М
М:М
М:М
1:M
1:М
М:М
1:М
1:1
М:М
1:1
М:1
М:1
М:М
42
2.1.3. Концептуальная модель данных в стандарте Чена.
N_klienta
Num_avto
ремонтир
приобр
КЛИЕНТ
АВТО
выда
получ
использу
Nomer_naklad
noy
ремонти
Detal_numbe
указываю
НАКЛАДНАЯ
МАТЕРИАЛЫ
выписыва
ет
выписыва
использу
заказы
применя
Nom_uslygi
использ
уют
выполняю
МАСТЕР
УСЛУГА
принима
ID_maste
ra
43
2.2. Этап логического проектирования.
2.2.1. ER-диаграмма в среде ERwin.
Анализ ER-диаграммы.
1. Многозначные атрибуты – нет
2. Производные атрибуты –
Накладная(сумма)
Услуга(стоимость)
Материалы(стоимость).
3. Связь 1:1
«Включается» – не требуется слияния, т.к. большое количество собственных атрибутов у
каждой сущности - участницы связи.
4. Рекурсивная связь – нет.
5. Избыточные связи:
1.мастер обслуживает клиента
2. мастер выполняет услуги
3.мастер ремонтирует авто
4. мастер использует материалы
5. клиент выбирает услуги
6.клиент принадлежит авто
7.клиент приобретает материалы
8. услуга применяется к авто
9. в накладной указываются материалы
10 авто использует материалы
44
6. Связь M:M – нет
Окончательная ER-диаграмма.
45
2.3 Этап физического проектирования.
Схема данных в среде выбранной СУБД.
3.
Разработка пользовательских интерфейсов
Этот раздел курсового проекта выполняется по согласованию с преподавателем.
Заключение.
Цель данного курсового проекта: разработать информационную систему для предприятия автосервис, - занимающегося оказанием услуг на автомобиль. Данная цель была достигнута мной
в ходе проектирования данной информационной системы.
За время работы над проектом я получил навыки по технологии проектирования
информационных систем, методики проектирования баз данных ER- диаграмм, методики анализа
деятельности предприятия, занимающегося предоставлением услуг проката автомобилей.
46
Список литературы, рекомендованной для подготовки курсового проекта.
Суркова Н.Е., Остроух А.В. Методы проектирования информационных систем: Учебное
пособие. – М.:РосНОУ, 2010. – 144 с.
Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и
сопровождение. Теория и практика, 2-е издание: Пер с англ.: Уч.пос. – М. : Изд.дом «Вильямс»,
2010. – 1120 с.
Акчурин Э.А. Человеко-машинное взаимодействие. Учебное пособие. – М.: СОЛОНПРЕСС, 2008. – 96 с.
Козлов А.С. Проектирование и исследование бизнес-процессов :учебное пособие – 3-е изд.
– М.: Флинта: МПСИ, 2009. – 272 с.