5. Пример пояснительной записки курсового проекта
5.1. Введение
Основной целью данного проекта является разработка информационной системы оперативного учета выпуска продукции и анализа работы предприятия.
Данная система должна решать следующие задачи:
сбор и хранение сведений о выпуске изделий каждым цехом,
сбор и хранение справочной информации о каждом изделии и деталях, из которых оно изготавливается;
получение результатов необходимых запросов,
выдача отчетов заданного образца о выпуске изделий и затратах на комплектующие детали;
редактирование, добавление и обновления базы данных;
обеспечение устойчивой работы и защиты базы данных от разрушения;
обеспечение определенной степени защиты и системы доступа.
Средой разработки программы является СУБД SQL SERVER 2005. Причинами, побудившими к работе с SQL SERVER 2005, являются следующие достоинства этого продукта: мощность, высокая скорость обработки запросов, наличие развитого языка процедурного программирования для создания приложения на сервере.
☻ Каждому автору предлагается сформулировать свою собственную цель курсового проектирования, выявить список своих задач и обосновать необходимость использования СУБД SQL SERVER 2005!
5.2. Пример оформления главы 1 « Проектирование базы данных»
5.2.1. Проектирование базы данных методом нормализации таблиц
Проектирование – важнейший этап создания любой базы данных. Неправильное проектирование может привести к ошибкам во время работы и невозможности решения некоторых задач.
☻ Обратите особое внимание на то, что для получения правильного проекта базы данных необходимо знать, какие задачи должны решаться на основе этой базы. Поэтому мы Вам настоятельно рекомендуем перед началом проектирования ознакомиться со всеми заданиями Вашего варианта курсового проекта!
Данные, которые должны храниться в базе, можно представить в виде одной таблицы (табл. 5.1)1.
Таблица 5.1
Исходные данные для проектирования
Код цеха |
Наиме-но- вание цеха |
Код изделия |
Наименование изделия |
Дата выпуска изделия |
Количество выпущен-ных изделий данного типа |
Код детали, входя-щей в изделие |
Наимено- вание детали |
Количест-во деталей каждого типа на одно изделие |
Цена детали, руб |
1 |
первый |
3 |
стол |
25.02.08 |
10 |
6 |
столешница |
1 |
1500 |
1 |
первый |
3 |
стол |
25.02.08 |
10 |
7 |
ножка стола |
4 |
500 |
2 |
второй |
4 |
гардероб |
26.02.08 |
15 |
1 |
корпус |
1 |
2000 |
2 |
второй |
4 |
гардероб |
26.02.08 |
15 |
2 |
дверь |
2 |
600 |
2 |
второй |
4 |
гардероб |
26.02.08 |
15 |
3 |
зеркало |
1 |
500 |
2 |
второй |
4 |
гардероб |
26.02.08 |
15 |
4 |
полка |
4 |
200 |
2 |
второй |
5 |
книжный шкаф |
26.02.08 |
10 |
1 |
корпус |
1 |
2000 |
Очевидно, такой способ хранения данных крайне неудобен и недопустим по причине наличия следующих недостатков:
избыточности данных (запись о выпуске какого-то одного изделия повторяется столько раз, сколько в нём деталей; все поля кроме полей, содержащих сведения о детали, дублируются; таблица громоздкая и неудобная для работы);
аномалий обновления (вследствие того, что наименования цеха, изделия, детали вводятся каждый раз при добавлении записи, возможны ошибки при вводе, а это может привести к тому, что какая-то запись не будет обнаружена при поиске всех записей; кроме того, если, например, один из цехов будет переименован, возникнет необходимость исправления множества записей);
аномалии удаления (чтобы удалить из базы данных какой-то один факт, например наименование ненужной детали, потребуется удалить все записи из таблицы, где эта деталь упоминается);
аномалии включения (если существуют изделия или детали, не участвующие в выпуске, информацию о них нельзя хранить в такой таблице).
Таким образом, исходную таблицу необходимо подвергнуть нормализации, то есть разбить её на несколько таблиц, обладающих лучшими свойствами при хранении, изменении, добавлении и удалении данных. Конечной целью является получение такого проекта базы данных, в котором каждый факт хранился бы только в одном месте.
Для этого следует привести таблицу к более высокой нормальной форме. Исходная таблица (табл. 5.1) находится в первой нормальной форме, потому что каждая её ячейка хранит атомарное (неделимое) значение и ни одно из ключевых полей не пусто.
Чтобы привести таблицу ко второй нормальной форме, необходимо выявить поля, которые будут первичными ключами в новых таблицах, и определить, какие из остальных полей находятся в полной функциональной зависимости от ключевых полей.
Поле «Наименование цеха» функционально зависит от поля «Код цеха» (для каждого кода обязательно существует одно наименование). Поэтому мы можем выделить их в отдельную таблицу (табл. 5.2) с первичным ключом «Код цеха». При этом в исходной таблице будет оставлено одноименное поле для связи со вновь созданной таблицей. Эта таблица будет связана с исходной таблицей отношением «один-ко-многим» по полю «Код цеха».
Поле «Наименование изделия» функционально зависит от поля «Код изделия» (для каждого кода обязательно существует одно наименование). Выделим их в отдельную таблицу (табл 5.3), первичным ключом в новой таблице является поле «Код изделия».
Таблица 5.2
Цеха
Код цеха |
Наименование цеха |
1 |
первый |
2 |
второй |
3 |
третий |
Таблица 5.3
Изделия
Код изделия |
Наименование изделия |
3 |
стол |
4 |
гардероб |
5 |
книжный шкаф |
Эта таблица будет связана с табл. 5.1 отношением «один-ко-многим» по полю «Код изделия».
Поля «Наименование детали» и «Цена детали» зависят от поля «Код детали» (для каждого кода обязательно существует одно наименование и одна цена). Выделим их в отдельную таблицу (табл. 5.4) с первичным ключом «Код детали».
Таблица 5.4
Детали
Код детали |
Наименование детали |
Цена детали, руб |
1 |
корпус |
2000 |
2 |
дверь |
600 |
3 |
зеркало |
500 |
4 |
полка |
200 |
5 |
полка |
400 |
6 |
столешница |
1500 |
7 |
ножка стола |
500 |
Поле «Количество деталей каждого типа на одно изделие» зависит от двух полей «Наименование изделия» и «Наименование детали», но эти поля функционально зависят от полей «Код изделия» и «Код детали» соответственно, поэтому вынесем в табл. 5.5 поля: «Код изделия», «Код детали», «Количество деталей каждого типа на одно изделие».
Таблица 5.5
Комплектующие детали
Код изделия |
Код детали |
Количество деталей каждого типа на одно изделие |
3 |
6 |
1 |
3 |
7 |
4 |
4 |
1 |
1 |
4 |
2 |
2 |
4 |
3 |
1 |
4 |
4 |
4 |
5 |
1 |
1 |
5 |
4 |
6 |
5 |
5 |
2 |
В данной таблице первичный ключ будет составным – «Код изделия» + «Код детали», потому что изделие в общем случае состоит из многих деталей, каждая из которых входит в изделие в определенном количестве. Одна и та же деталь, в принципе, может использоваться в различных изделиях. Сочетание полей «Код детали» и «Код изделия» будут уникальны в каждой строке таблицы. Поле «Количество деталей» находится в полной функциональной зависимости от первичного ключа, потому что каждому значению составного ключа соответствует одно значение поля «Количество деталей», а значениям полей «Код изделия» и «Код детали» по-отдельности соответствует несколько значений поля «Количество деталей», то есть функциональная зависимость отсутствует.
Эта таблица будет связана с табл. 5.3 по полю «Код изделия» отношением «много-к-одному» и с таблицей 5.4 по полю «Код детали» отношением «много-к-одному».
В результате выделения функционально зависимых полей в отдельные таблицы, исходная таблица (табл 5.1) будет преобразована к табл. 5.6.
Таблица 5.6
Выпуск изделий
Код цеха |
Код изделия |
Дата выпуска изделия |
Количество выпущенных изделий данного типа |
1 |
3 |
25.02.08 |
10 |
2 |
4 |
26.02.08 |
15 |
2 |
5 |
26.02.08 |
10 |
1 |
3 |
26.02.08 |
20 |
Первичный ключ в последней таблице также составной («Код цеха» + «Код изделия» + «Дата выпуска изделия»), так как сведения о выпуске всех изделий определенного наименования в каждом цеху на каждую дату в эту таблицу заносятся одной строкой.
Таким образом, исходная таблица разделена на пять таблиц во второй нормальной форме. Далее, чтобы привести таблицы к третьей нормальной форме, необходимо устранить транзитивную зависимость между полями, другими словами, ни одно неключевое поле не должно функционально зависеть от другого неключевого поля. Таблицы 5.2, 5.3, 5.5 уже находятся в третьей нормальной форме, так как каждая из них содержит только одно неключевое поле, связанное функциональной зависимостью с ключевым. В табл. 5.4 имеются два неключевых поля («Наименование детали» и «Цена детали»), которые зависят от первичного ключа «Код детали». Так как наименования деталей могут повторяться, и некоторые детали могут иметь одинаковые цены, нельзя говорить о какой-либо транзитивной зависимости между этими полями. Таким образом, табл. 5.4 также находится в третьей нормальной форме.
В
результате нормализации получаем пять
таблиц, которые находятся в третьей
нормальной форме. Таблицы связаны между
собой отношениями «один-ко-многим» и
«много-к-одному» (см. рис. 5.1).
Рис.5.1. Таблицы базы данных, полученные в результате нормализации
В результате мы избавились от недостатков, присущих исходной таблице. В полученном проекте отсутствует вредная избыточность, приводящая к потенциальной противоречивости данных. В таблицы - справочники (см. табл. 5.2-5.4) легко можно добавить новые сведения, если потребуется исправить какие-либо данные (например, название цеха), исправление будет сделано только в одной строке табл. 5.2. В проекте отсутствуют и аномалии удаления. Однако здесь следует оговорить тот факт, что удалить можно только те строки в родительских таблицах, на которые нет ссылок в дочерних таблицах.
☻ Каждому автору предлагается после завершения описания процесса нормализации так же обосновать, чем полученный проект лучше исходного.