|
Читайте также: |
база данных SQL Server 2005.
Курсовое проектирование
Самара 2014
Оглавление
Введение. 2
1. Цель и задачи работы над курсовым проектом. 3
2. Структура пояснительной записки. 4
3. ОБЩИЕ ТРЕБОВАНИЯ К ВЫПОЛНЕНИЮ КУРСОВого проекта и содержанию пояснительной записки. 5
4. Пример задания на курсовое проектирование. 6
5. Пример пояснительной записки курсового проекта. 10
5.1. Введение. 10
5.2. Пример оформления главы 1 «Проектирование. 10
базы данных». 10
5.2.1. Проектирование базы данных методом нормализации таблиц. 10
5.1.2. Проектирование базы данных методом семантического. 17
моделирования в среде Erwin. 17
5.3. Пример оформления главы 2 «Создание таблиц в SQL Server 2005». 19
5.3.1. Команды создания и модификации таблиц. 19
5.3.3. Просмотр структуры и содержимого таблиц. 27
5.4. Пример оформления главы 3 «Основные команды SQL для извлечения, добавления и изменения данных». 28
5.5. Пример оформления главы 4. «Создание процедур и функций». 37
5.7. Пример оформления главы 5 «Создание триггеров». 42
5.8. Пример оформления заключения по курсовому проекту. 47
6. Нормативные требования к оформлению курсового проекта. 48
Приложение 1. 53
Приложение 2. 54
Варианты заданий для курсового проектирования. 54
Вариант 1. 54
Вариант 2. 56
Вариант 3. 59
Вариант 4. 61
Вариант 5. 64
Вариант 6. 66
Вариант 7. 69
Вариант 8. 71
Вариант 9. 73
Вариант 10. 76
Вариант 11. 78
Вариант 12. 80
Вариант 13. 82
Вариант 14. 85
Вариант 15. 87
Вариант 16. 90
Вариант 17. 93
Вариант 18. 95
Вариант 19. 98
Вариант 20. 101
Вариант 21. 103
Вариант 22. 106
Вариант 23. 108
Вариант 24. 111
Вариант 25. 114
Вариант 26. 117
введение
Системы управления базами данных (СУБД) в настоящее время стали практически обязательной частью любой информационной системы. Эффективность работы информационной системы во многом зависит от качества проекта базы данных, обоснованности проектных решений, а также умения грамотно манипулировать данными. Эти задачи предлагается решать в курсовом проекте по дисциплине «Базы данных».
Основная цель проектирования базы данных (БД) – это, в первую очередь, устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же явлении, а также сокращение избыточности хранимых данных и экономия объема памяти. Для создания классического проекта БД («Каждый факт в одном месте») в курсовом проекте предлагается применение методологии нормализации отношений и семантического моделирования. Для моделирования структуры данных используется пакет Erwin.
Для формирования базы данных, разработки запросов, процедур, триггеров и т.д. выбрана СУБД SQL Server 2005, которая ориентирована на работу в корпоративных сетях. В ней обеспечивается надежность, безопасность, высокая производительность, масштабируемость проектных решений. Данная СУБД отвечает всем требованиям, предъявляемым к реляционным СУБД. СУБД SQL Server 2005 является одной из наиболее популярных СУБД как в России, так и за рубежом.
Пособие состоит из шести разделов. В первом разделе изложены цели и задачи курсового проектирования, во втором дана структура пояснительной записки, в третьем разделе описаны требования к выполнению курсового проекта и содержанию пояснительной записки. В разделах с 4 и 5 настоящего пособия дан пример варианта задания по курсовому проектированию и приведены примеры описания некоторых глав курсового проекта, выполнение которых обычно вызывает определенные трудности у студентов. В шестой главе пособия приведены нормативные требования к оформлению текста курсового проекта. В приложении содержатся детально разработанные варианты для контрольной работы и курсового проекта.
1. Цель и задачи работы над курсовым проектом
Целями подготовки и защиты студентами курсового проекта являются:
· систематизация и закрепление теоретических и практических знаний в области проектирования баз данных (БД);
· приобретение навыков самостоятельной учебной и исследовательской работы со специальной литературой по теории и практике решения экономических задач;
· углубленное изучение системы управления базами данных (СУБД) SQL Server;
· овладение практическими навыками использования языка Transact SQL для разработки пользовательского приложения в среде СУБД SQL Server 2005, содержащего элементы автоматизации информационных процессов в экономике.
При выполнении курсового проекта студент должен самостоятельно освоить теоретический материал по проектированию и созданию БД [1-3]. В соответствии с выданным вариантом задания на курсовое проектирование студент должен создать инфологическую модель, даталогическую и физическую модели БД, ориентированные на СУБД SQL Server 2005.
Для реализации поставленных в курсовом проекте задач следует разработать пользовательское приложение, содержащее ряд структурных и программных элементов. В среде СУБД SQL Server 2005 необходимо создать собственную базы данных, содержащую таблицы в соответствии с разработанной даталогической моделью данных. Для каждой таблицы следует разработать все необходимые средства, обеспечивающие целостность базы данных: первичные и внешние ключи, умолчания, правила проверки данных при вводе. В соответствии с заданным вариантом проекта необходимо создать запросы, процедуры, функции и триггеры.
2. Структура пояснительной записки
Пояснительная записка по выполненному курсовому проекту должна содержать следующие разделы.
Титульный лист с названием проекта (см. прилож. 1).
Задание на курсовое проектирование.
Оглавление.
Введение.
Основные разделы проекта.
Заключение.
Библиографический список.
Приложения.
Задание на проектирование выдается руководителем. Оглавление пояснительной записки представляет собой перечень основных частей выполненного проекта: разделов, пунктов, подпунктов с указанием соответствующих страниц записки.
Введение должно содержать общую характеристику решаемой задачи, обоснование целесообразности ее решения с помощью СУБД выбранного типа.
Основные разделы пояснительной записки должны включать описание главных пунктов задания:
· проектирование базы данных методом нормализации таблиц и с помощью построения диаграммы «сущность-связь»;
· создание базы данных в среде СУБД SQL Server 2005;
· создание запросов и команд манипулирования данными;
· создание процедур и функций;
· разработку триггеров;
Заключение должно содержать выводы о проделанной работе, рекомендации по дальнейшему развитию и совершенствованию созданного приложения.
3. ОБЩИЕ ТРЕБОВАНИЯ К ВЫПОЛНЕНИЮ КУРСОВого проекта и содержанию пояснительной записки
В первой главе Вашего курсового проекта необходимо описать процесс проектирования базы в соответствии с Вашим вариантом задания. Вы должны показать два способа проектирования: с помощью процесса нормализации таблиц и с помощью семантического моделирования.
В первом параграфе данной главы Вам необходимо выявить и описать недостатки исходной однотабличной базы данных и провести ее нормализацию. Выделяя функциональные зависимости между полями таблицы, Вы должны сформировать несколько таблиц, обладающих лучшими свойствами при обновлении, добавлении и удалении данных и имеющих меньшую избыточность. Таблицы должны быть приведены к третьей нормальной форме или нормальной форме Бойса-Кодда (НФБК).
Во втором параграфе данной главы Вы должны показать другой способ проектирования БД на основе модели «Сущность-связь». Вам необходимо представить алгоритм выявления сущностей, установить атрибуты сущностей, а также связи между сущностями. Семантическое моделирование следует провести средствами пакета ERWin. Полученные ER-диаграммы на логическом и физическом уровнях следует представить в виде рисунков в основном тексте или привести в приложении. Пример оформления первой главы проекта представлен в разд. 5.2.
Во второй главе Вам следует описать процесс создания базы данных и спроектированных Вами таблиц в среде SQL Server 2005. Желательно, чтобы имена всех создаваемых в проекте компонентов отражали специфику задания Вашего варианта. Таблицы следует заполнить данными и представить в проекте распечатки структур и содержимого таблиц. Вы должны построить диаграмму базы данных, создать в каждой таблице первичные ключи, установить постоянные отношения между таблицами и организовать ссылочную целостность таблиц (см. пример в разд. 5.3).
В третьей главе Вы должны описать процесс создания запросов и других команд манипулирования данными в соответствии с Вашим вариантом задания. Обязательно следует привести текст каждой SQL команды и ее результат. Правильность работы каждого запроса и других SQL команд Вы должны доказать с помощью контрольных примеров (разд. 5.4).
В четвертой и пятой главах следует описать процессы создания процедур, функций (разд. 5.5) и триггеров (разд. 5.6), созданных с помощью языка программирования Transact-SQL. Вы должны привести тексты соответствующих процедур со всеми необходимыми для понимания их работы комментариями, показать результаты их работы при всех возможных вариантах в зависимости от исходных параметров, и там, где это требуется подтвердить правильность работы процедур с помощью контрольных примеров.
Варианты задания приведены в прилож. 2.
В тексте пособия расположены комментарии авторов, выделенные курсивом и заключенные в рамку следующего вида, которые предназначены для того, чтобы читатели обратили особое внимание на ту или иную проблему. Выглядят эти комментарии следующим образом:
☻ Обратите особое внимание на ….
Читайте внимательно комментарии и следуйте их рекомендациям!
☻ В шестом разделе данного пособия приведены нормативные требования к оформлению текста, таблиц, рисунков, приложения и т.д., и т.п. Курсовой проект, не отвечающий данным требованиям, не будет допущен к защите.
4. Пример задания на курсовое проектирование
1. В первой главе курсового проекта описать процесс проектирования базы данных. Спроектировать базу данных методом нормализации и методом семантического моделирования. Данные, которые должны храниться в базе, представлены в виде одной таблицы со следующими столбцами:
Код цеха
Наименование цеха
Код изделия
Наименование изделия
Дата выпуска изделия
Количество выпущенных изделий данного типа
Код детали, входящей в изделие
Наименование детали
Количество деталей каждого типа на одно изделие
Цена детали
Во второй главе описать процесс создания базы данных и таблиц в соответствии с Вашим проектом в среде SQL Server 2005. Для одной из таблиц создать сценарий для создания таблицы и заполнения ее данными. Номенклатура выпускаемых изделий должна содержать не менее 10 наименований, список цехов содержать не менее трех наименований, каждое изделие должно состоять из 1-3 деталей. Сведения о выпуске изделий должно содержать не менее 20 строк. Предусмотреть в создаваемых таблицах ограничения целостности следующих типов:
¨ NOT NULL – для полей, которые будут являться первичными и внешними ключами,
¨ PRIMARY KEY – для полей, выбранных в качестве первичных ключей,
¨ FOREIGN KEY – для полей, являющихся внешними ключами,
CHECK для полей «Дата выпуска изделий» (не позже системной даты), а также для полей «Количество деталей на одно изделие», «Количество выпущенных изделий данного типа» (их значения должны быть положительными числами).
Создать таблицы в конструкторе среды SQL Server 2005 Management Studio Express. Для создания одной из таблиц напишите сценарий, содержащий команду создания таблицы и заполнения ее данными.
Исправить ошибки. Просмотреть структуры таблиц и содержимое самих таблиц.
Команды сценария, структуры таблиц и содержимое таблиц привести во второй главе пояснительной записки к курсовому проекту «Создание таблиц в SQL Server 2005».
4. В третьей главе курсового проекта «Основные команды SQL для извлечения, добавления и изменения данных» выполнить следующие действия и представить их результаты.
4.1. Показать список выпущенных изделий в заданном цехе. В запросе вывести поля: код и наименование цеха, код и наименование изделия, количество выпущенных изделий, дату выпуска.
4.2. Преобразовать предыдущий запрос таким образом, чтобы он выводил список выпущенных изделий за заданный календарный период.
4.3. В новую таблицу поместить сведения об общем выпуске изделий каждого наименования, выпуск которых превышает среднее количество выпущенных изделий. Показать поля: наименование изделия, общий выпуск данного изделий, средний выпуск среди всех изделий.
4.4. Для определенного вида изделий показать список всех деталей, необходимых для его изготовления. Показать поля: код и наименование изделия, код и наименование детали, количество деталей, цена детали, стоимость общего количества каждого типа детали.
4.5. Изменить цену определенной детали на 10%.
4.6. Изменить цену на 2% тех деталей, цена которых ниже средней цены.
5. В четвертой главе должны быть представлены процедуры и функции, разработанные в среде SQL Server 2005 с помощью языка программирования Transact-SQL.
5.1. Создать функцию для подсчета затрат на комплектующие для определенного вида изделия.
5.2. Создать процедуру для выдачи сведений о выпуске определенного изделия в определенном цехе (использовать номер цеха и код изделия в качестве параметров процедуры). Процедура должна выдавать номер цеха, дату выпуска, наименование изделия, наименование детали, количество деталей на одно изделие, стоимость комплектующих на одну деталь, стоимость комплектующих на весь выпуск, а затем найти и вывести общую стоимость деталей на изделие и общую стоимость деталей на весь выпуск.
5.3. Создать процедуру для выдачи списка изделий определенного изделия (код изделия задать в качестве параметра процедуры). В процедуре организовать проверку на правильность задания параметра, и если данный код отсутствует в таблице izd_det, выдать сообщение об ошибке.
6. В пятой главе представить разработанные с помощью языка Transact-SQL триггеры:
6.1. Создать триггер, который бы перед добавлением новой записи в таблицу, содержащую сведения о комплектующих деталях для каждого вида изделия, проверял проверку правильности ввода кода изделия и кода детали и выдавал ошибку с соответствующим текстом (например, нет изделия с кодом … в списке изделий).
6.2. Создать таблицу с помощью запроса со следующими полями: код изделия, стоимость комплектующих на одно изделие. Написать триггер на изменение цены какой-либо детали, который бы сразу же корректировал соответствующую запись в созданной таблице.
5. Пример пояснительной записки курсового проекта
5.1. Введение
Основной целью данного проекта является разработка информационной системы оперативного учета выпуска продукции и анализа работы предприятия.
Данная система должна решать следующие задачи:
· сбор и хранение сведений о выпуске изделий каждым цехом,
· сбор и хранение справочной информации о каждом изделии и деталях, из которых оно изготавливается;
· получение результатов необходимых запросов,
· выдача отчетов заданного образца о выпуске изделий и затратах на комплектующие детали;
· редактирование, добавление и обновления базы данных;
· обеспечение устойчивой работы и защиты базы данных от
разрушения;
· обеспечение определенной степени защиты и системы доступа.
Средой разработки программы является СУБД SQL SERVER 2005. Причинами, побудившими к работе с SQL SERVER 2005, являются следующие достоинства этого продукта: мощность, высокая скорость обработки запросов, наличие развитого языка процедурного программирования для создания приложения на сервере.
☻ Каждому автору предлагается сформулировать свою собственную цель курсового проектирования, выявить список своих задач и обосновать необходимость использования СУБД SQL SERVER 2005!
5.2. Пример оформления главы 1 «Проектирование
базы данных»
5.2.1. Проектирование базы данных методом нормализации таблиц
Проектирование – важнейший этап создания любой базы данных. Неправильное проектирование может привести к ошибкам во время работы и невозможности решения некоторых задач.
☻ Обратите особое внимание на то, что для получения правильного проекта базы данных необходимо знать, какие задачи должны решаться на основе этой базы. Поэтому мы Вам настоятельно рекомендуем перед началом проектирования ознакомиться со всеми заданиями Вашего варианта курсового проекта!
Данные, которые должны храниться в базе, можно представить в виде одной таблицы (табл. 5.1)[1].
Таблица 5.1
Исходные данные для проектирования
| Код цеха | Наиме-но- вание цеха | Код изделия | Наименование изделия | Дата выпуска изделия | Количество выпущен-ных изделий данного типа | Код детали, входя-щей в изделие | Наимено- вание детали | Количест-во деталей каждого типа на одно изделие | Цена детали, руб |
| первый | стол | 25.02.08 | столешница | ||||||
| первый | стол | 25.02.08 | ножка стола | ||||||
| второй | гардероб | 26.02.08 | корпус | ||||||
| второй | гардероб | 26.02.08 | дверь | ||||||
| второй | гардероб | 26.02.08 | зеркало | ||||||
| второй | гардероб | 26.02.08 | полка | ||||||
| второй | книжный шкаф | 26.02.08 | корпус |
Очевидно, такой способ хранения данных крайне неудобен и недопустим по причине наличия следующих недостатков:
· избыточности данных (запись о выпуске какого-то одного изделия повторяется столько раз, сколько в нём деталей; все поля кроме полей, содержащих сведения о детали, дублируются; таблица громоздкая и неудобная для работы);
· аномалий обновления (вследствие того, что наименования цеха, изделия, детали вводятся каждый раз при добавлении записи, возможны ошибки при вводе, а это может привести к тому, что какая-то запись не будет обнаружена при поиске всех записей; кроме того, если, например, один из цехов будет переименован, возникнет необходимость исправления множества записей);
· аномалии удаления (чтобы удалить из базы данных какой-то один факт, например наименование ненужной детали, потребуется удалить все записи из таблицы, где эта деталь упоминается);
· аномалии включения (если существуют изделия или детали, не участвующие в выпуске, информацию о них нельзя хранить в такой таблице).
Таким образом, исходную таблицу необходимо подвергнуть нормализации, то есть разбить её на несколько таблиц, обладающих лучшими свойствами при хранении, изменении, добавлении и удалении данных. Конечной целью является получение такого проекта базы данных, в котором каждый факт хранился бы только в одном месте.
Для этого следует привести таблицу к более высокой нормальной форме. Исходная таблица (табл. 5.1) находится в первой нормальной форме, потому что каждая её ячейка хранит атомарное (неделимое) значение и ни одно из ключевых полей не пусто.
Чтобы привести таблицу ко второй нормальной форме, необходимо выявить поля, которые будут первичными ключами в новых таблицах, и определить, какие из остальных полей находятся в полной функциональной зависимости от ключевых полей.
Поле «Наименование цеха» функционально зависит от поля «Код цеха» (для каждого кода обязательно существует одно наименование). Поэтому мы можем выделить их в отдельную таблицу (табл. 5.2) с первичным ключом «Код цеха». При этом в исходной таблице будет оставлено одноименное поле для связи со вновь созданной таблицей. Эта таблица будет связана с исходной таблицей отношением «один-ко-многим» по полю «Код цеха».
Поле «Наименование изделия» функционально зависит от поля «Код изделия» (для каждого кода обязательно существует одно наименование). Выделим их в отдельную таблицу (табл 5.3), первичным ключом в новой таблице является поле «Код изделия».
Таблица 5.2
Цеха
| Код цеха | Наименование цеха |
| первый | |
| второй | |
| третий |
Таблица 5.3
Изделия
| Код изделия | Наименование изделия |
| стол | |
| гардероб | |
| книжный шкаф |
Эта таблица будет связана с табл. 5.1 отношением «один-ко-многим» по полю «Код изделия».
Поля «Наименование детали» и «Цена детали» зависят от поля «Код детали» (для каждого кода обязательно существует одно наименование и одна цена). Выделим их в отдельную таблицу (табл. 5.4) с первичным ключом «Код детали».
Таблица 5.4
Детали
| Код детали | Наименование детали | Цена детали, руб |
| корпус | ||
| дверь | ||
| зеркало | ||
| полка | ||
| полка | ||
| столешница | ||
| ножка стола |
Поле «Количество деталей каждого типа на одно изделие» зависит от двух полей «Наименование изделия» и «Наименование детали», но эти поля функционально зависят от полей «Код изделия» и «Код детали» соответственно, поэтому вынесем в табл. 5.5 поля: «Код изделия», «Код детали», «Количество деталей каждого типа на одно изделие».
Таблица 5.5
Комплектующие детали
| Код изделия | Код детали | Количество деталей каждого типа на одно изделие |
В данной таблице первичный ключ будет составным – «Код изделия» + «Код детали», потому что изделие в общем случае состоит из многих деталей, каждая из которых входит в изделие в определенном количестве. Одна и та же деталь, в принципе, может использоваться в различных изделиях. Сочетание полей «Код детали» и «Код изделия» будут уникальны в каждой строке таблицы. Поле «Количество деталей» находится в полной функциональной зависимости от первичного ключа, потому что каждому значению составного ключа соответствует одно значение поля «Количество деталей», а значениям полей «Код изделия» и «Код детали» по-отдельности соответствует несколько значений поля «Количество деталей», то есть функциональная зависимость отсутствует.
Эта таблица будет связана с табл. 5.3 по полю «Код изделия» отношением «много-к-одному» и с таблицей 5.4 по полю «Код детали» отношением «много-к-одному».
В результате выделения функционально зависимых полей в отдельные таблицы, исходная таблица (табл 5.1) будет преобразована к табл. 5.6.
Таблица 5.6
Выпуск изделий
| Код цеха | Код изделия | Дата выпуска изделия | Количество выпущенных изделий данного типа |
| 25.02.08 | |||
| 26.02.08 | |||
| 26.02.08 | |||
| 26.02.08 |
Первичный ключ в последней таблице также составной («Код цеха» + «Код изделия» + «Дата выпуска изделия»), так как сведения о выпуске всех изделий определенного наименования в каждом цеху на каждую дату в эту таблицу заносятся одной строкой.
Таким образом, исходная таблица разделена на пять таблиц во второй нормальной форме. Далее, чтобы привести таблицы к третьей нормальной форме, необходимо устранить транзитивную зависимость между полями, другими словами, ни одно неключевое поле не должно функционально зависеть от другого неключевого поля. Таблицы 5.2, 5.3, 5.5 уже находятся в третьей нормальной форме, так как каждая из них содержит только одно неключевое поле, связанное функциональной зависимостью с ключевым. В табл. 5.4 имеются два неключевых поля («Наименование детали» и «Цена детали»), которые зависят от первичного ключа «Код детали». Так как наименования деталей могут повторяться, и некоторые детали могут иметь одинаковые цены, нельзя говорить о какой-либо транзитивной зависимости между этими полями. Таким образом, табл. 5.4 также находится в третьей нормальной форме.
В результате нормализации получаем пять таблиц, которые находятся в третьей нормальной форме. Таблицы связаны между собой отношениями «один-ко-многим» и «много-к-одному» (см. рис. 5.1).
Рис.5.1. Таблицы базы данных, полученные в результате нормализации
В результате мы избавились от недостатков, присущих исходной таблице. В полученном проекте отсутствует вредная избыточность, приводящая к потенциальной противоречивости данных. В таблицы - справочники (см. табл. 5.2-5.4) легко можно добавить новые сведения, если потребуется исправить какие-либо данные (например, название цеха), исправление будет сделано только в одной строке табл. 5.2. В проекте отсутствуют и аномалии удаления. Однако здесь следует оговорить тот факт, что удалить можно только те строки в родительских таблицах, на которые нет ссылок в дочерних таблицах.
☻ Каждому автору предлагается после завершения описания процесса нормализации так же обосновать, чем полученный проект лучше исходного.
5.1.2. Проектирование базы данных методом семантического
моделирования в среде Erwin
Семантическое моделирование, или моделирование структуры данных на основе их смыслового содержания, осуществляется при помощи диаграмм ER (сущность-связь). Такой метод проектирования позволяет изобразить структуру базы данных с применением графических средств. По сравнению с другими методами проектирования данный метод более наглядный.
Чтобы построить ER-модель, необходимо выполнить ряд этапов. В первую очередь, надо определить, какие сущности будут присутствовать в модели.
Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Каждая сущность имеет несколько экземпляров. Данным определениям в нашем варианте задания соответствуют следующие сущности:
· Цех;
· Изделие;
· Деталь;
· Выпуск.
На следующем этапе мы должны определить атрибуты каждой сущности.
Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Один или несколько атрибутов должны определять уникальность каждого экземпляра сущности, т.е. представлять собой первичный ключ сущности (Primary Key – PK).
Сущность «Цех» характеризуется следующими атрибутами: код цеха (тип данных Number, Primary Key), наименование цеха (тип данных String).
Сущность «Изделие» имеет следующие атрибуты: код изделия (тип данных Number, Primary Key), наименование изделия (тип данных String).
В сущность «Деталь» входят атрибуты: код детали (тип данных Number, Primary Key), наименование детали (тип данных String), цена детали (тип данных Number).
Сущность «Выпуск»включает в себя следующий набор атрибутов: дата (тип Datetime), количество (тип данных Number).
После создания сущностей с атрибутами следует создать связи между сущностями. Сущности «Цех» и «Изделие» связываются с сущностью «Выпуск» отношением «один-ко-многим» (Identifying relationship). В сущность «Выпуск» автоматически добавляются атрибуты – внешние ключи «Код изделия» и «Код цеха».
Сущности «Изделие» и «Деталь» связываются отношением «много-ко-многим» (Non-identifying relationship). Затем в контекстном меню на линии связи выбирается команда Resolve Many-to-Many, автоматически создается новая сущность «Изделие_Деталь», содержащая внешние ключи «Код изделия» и «Код детали». В данную сущность добавляется последний необходимый атрибут – количество каждой детали в данном изделии (тип данных Number).
Получившаяся модель на логическом уровне представлена на на рис. 5.2.
☻ Обращаем внимание на то, что в Вашем курсовом необходимо привести семантическую модель базы данных, как на логическом, так и на физическом уровнях!!!
Рис. 5.2. Модель «сущность-связь»
5.3. Пример оформления главы 2 «Создание таблиц в SQL Server 2005»
5.3.1. Команды создания и модификации таблиц
Для создания таблиц и других объектов, для изменения их свойств, а также удаления, используются команды DDL[2]: CREATE, ALTER, DROP и др.
Прежде чем создавать таблицы, необходимо создать базу данных пользователя, в которой они будут располагаться.
Для этого необходимо на рубрике Базы данных (Databases) вызвать команду контекстного меню Создать базу и в появившемся окне ввести имя базы данных.
 |
Рис. 5.3. Создание таблицы detal в конструкторе
В команде создания таблицы описываются поля таблицы с указанием имени, типа, ширины поля и ограничений.
Общий вид команды создания таблицы:
Create table <имя таблицы> (имя поля1 тип[ширина] [default] [not null] [constraint], имя поля2 …)
Констрейнты (ограничения целостности) позволяют поддерживать уникальность записи, присваивать значения null и not null, поддерживать ограничения полей в заданных рамках, обеспечивать взаимную целостность таблиц. Различают констрейнты на уровне таблиц (применяются к одному или нескольким полям) и констрейнты на уровне полей (применяются к одному полю). Рассмотрим основные типы констрейнтов:
· ограничение NOT NULL запрещает оставлять заданное поле не заполненным, т.е. получать неопределенное значение;
· ограничение DEFAULT позволяет присвоить определенному полю значение по умолчанию; данное значение будет актуальным в том случае, если пользователь не введет в поле никакого иного значения;
· ограничение CHECK используется для проверки допустимости данных, вводимых в конкретное поле таблицы; ограничения целостности CHECK задают диапазон возможных значений для поля или полей; в основе ограничений целостности CHECK лежит использование логических выражений;
· ограничение UNIQUE задает требование уникальности значения поля или группы полей, входящих в уникальный ключ, по отношению к другим записям;
· ограничение целостности PRIMARY KEY (первичный ключ) – это поле или группа полей, уникально идентифицирующих каждую запись в таблице; данное ограничение необходимо для обеспечения целостности таблицы, а также ссылочной целостности;
· ограничение внешнего ключа FOREIGN KEY - это основной механизм для поддержания ссылочной целостности между таблицами реляционной базы данных; поле дочерней таблицы, определенное в качестве внешнего ключа в параметре FOREIGN KEY, применяется для ссылки на поле родительской таблицы, являющееся в ней первичным ключом; для разрешения каскадного изменения поля в дочерней таблице при изменении родительской таблицы применяются параметры ON DELETE CASCADE и ON UPDATE CASCADE.
Для внесения изменений в структуру таблицы используется команда ALTER TABLE. В зависимости от используемых параметров она может применяться для создания, модификации и удаления полей, создания констрейнтов.
Для заполнения таблиц данными можно использовать конструктор среды SQL Server 2004 Management Studio Express или команду INSERT[3].
Команда создания таблицы cex (Цеха) с полями kod_c (Код цеха) и name_c (Имя цеха), где kod_c - первичный ключ, приведена на рис. 5.4. Здесь же показано создание последовательности для формирования первичного ключа, начиная от единицы с шагом единица, и команды для добавления данных в таблицу.
|
Рис. 5.5
Для создания таблицы izdel (Изделие) с полями kod_i (Код изделия) и name_i (Имя изделия), где kod_i - первичный ключ, был использован конструктор среды SQL Server 2005 (рис. 5.6). На этом же рисунке показано создание поля kod_i, которое будет первичным ключом. Кроме того, это поле является полем Identity (идентифицируемым, т.е. формирующимся автоматически в каждой новой записи с начальным значением 10 и приращением 10).
|
Рис. 5.6
На следующей строке конструктора следует описать поле name_i, выбрав для него тип VARCHAR(25). Затем окно конструктора следует закрыть и ввести имя таблицы detal.
Для ввода данных в таблицу выполним команду «Открыть таблицу»контекстного меню на имени таблицы и ввести значения для поля name_i. Поле kod_i заполнится автоматически!
Аналогичным образом создаются все остальные таблицы.
Дата добавления: 2015-10-16; просмотров: 98 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Глава 7. Безмолвное слово как щит и меч | | | Построение диаграммы базы данных |