Федеральное агентство по образованию
ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР)
Кафедра комплексной информационной безопасности электронных вычислительных систем
(КИБЭВС)
Проектирование учебно-исследовательской базы данных
" Накладные "
Пояснительная записка к курсовой работе по дисциплине
«Базы данных»
Студент гр. 523-3
____________ Н.В. Власов
«___»_______________ 2005 г.
Руководитель курсовой работы
_____________ М.А.Сопов
«___»_______________ 2005 г.
2005
 Федеральное агентство по образованию
ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР)
Кафедра комплексной информационной безопасности электронных вычислительных систем (КИБЭВС)
ЗАДАНИЕ
Исследовать заданную предметную область, выбрать существенные атрибуты. Построить концептуальную модель предметной области.
На основе концептуальной модели построить реляционную модель, установить связи между объектами. Задать первичные и внешние ключи. Провести нормализацию.
Объяснить выполненные преобразования.
Провести исследование полученной модели, задав несколько сложных запросов к полученной модели.
Предметная область:
Накладная, магазины, продавец, центральный офис.
Накладная выписывается продавцом на несколько видов товаров, в магазине несколько продавцов. Продавец может выписывать несколько накладных, одинаковые товары могут продаваться в разных магазинах. Продавец работает только в одном магазине.
Дата выдачи задания: “____”_______ 2005 г.
Задание принято к исполнению
«____» ___________ 2005г. Подпись студента___________
Содержание
1. Введение………………………………………………………………………4
2. Построение концептуальной модели…………………………………….......5
3. Построение реляционной модели…………………………………………….7
4. Нормализация…………………………………………………………………..8
5. Проектирование базы данных в ACCESS…………………………………..10
6. Создание SQL запросов………………………………………………………14
7. Заключение……………………………………………………………………19
Список использованных источников…………………………………………...20
1. Введение
База данных, говоря коротко - это средство для реляционного и эффективного хранения информации. Иными словами, такая база обеспечивает надежную защиту данных от случайной потери или порчи, экономно использует ресурсы (как людские, так и технические) и снабжена механизмами поиска информации, удовлетворяющим разумным требованиям к производительности. Само понятие база данных может означать как отдельный набор данных (например, список телефонов), так и гораздо более сложную систему (например, SQL Server). Базы данных – это один из самых сложных типов коммерческих приложений. Все остальные типы системы, как правило, имеют более – менее близкие аналогии в реальном мире. С точки зрения практического использования текстовые процессоры – это усовершенствованная пишущая машинка. Электронную базу данных, несомненно, освоит не только бухгалтер, но и другой любой пользователь.
2. Построение концептуальной модели
Построение концептуальной модели представляет собой процесс моделирования смыслового наполнения базы данных. Концептуальная модель состоит из следующих трёх основных компонентов.
1. Сущности. Это элементы реального мира, которые могут существовать независимо. В моем случае сущностями являются: проект, детали, поставщики, заказ, служащие. Сущность представляется в концептуальной модели прямоугольником, в котором указано её имя.
2. Атрибуты. Атрибуты описывают сущность. Они представляются овалами с указанием имен, которые прикреплены к сущности. В моем случае проекту соответствуют: номер проекта. Деталям соответствуют: размер, номер детали, маркировка, название. Поставщикам соответствуют: ФИО, ИНН, адрес, идентификационный номер поставщика. Заказу соответствуют: номер заказа, номер проекта, номер деталей, идентификационный номер поставщика. Служащим соответствуют: ФИО, ИНН, должность.
3. Связи. Связь представляет взаимодействие между сущностями. На диаграмме она изображается ромбом, который соединяет сущности, участвующие в связи. В моем случае связь между проектом и служащими будет один ко многим, так как один проект может делать несколько служащих. Связь между служащими и заказом мы обозначим много ко многим, так как один служащий может делать много заказов. Связь между заказом и деталями мы обозначим много ко многим, так как много заказов могут быть на много деталей. Связь между заказом и поставщиками мы обозначим много ко многим, так как заказов может быть много и поставщиков тоже может быть несколько. Связь поставщики и детали мы обозначим много ко многим, так как несколько поставщиков могут поставлять разные детали. Связь детали и служащие мы обозначим, как много ко многим, так как служащие получают несколько типов деталей для каждого проекта. На рисунке 2.1 представлена концептуальная модель заданной базы данных.
Рисунок 2.1 – Концептуальная модель
3. Построение реляционной модели
 В реляционной базе данных все данные хранятся в таблицах. Названия сущностей станут заголовками таблиц, а атрибуты станут столбцами. Целостность данных в реляционной базе данных основывается на концепции ключей. Первичный ключ (PK) – это атрибут который можно использовать для уникальной идентификации таблицы. Так у таблицы “поставщики” - ключом станет идентификационный номер поставщика, мы обозначили как “id_P”; у таблицы “детали” - номер детали мы обозначили как “id_D”, у таблицы “проект” - номер проекта мы обозначили как “id_R”, таблица “служащие” мы обозначили как “id_S”, а таблица “заказ” - номер заказа мы обозначили как “id_Z”. Внешний ключ (FK) – это атрибут, который существует в нескольких таблицах и является первичным ключом одной из этих таблиц. Связь проводим от первичного ключа одой таблицы до внешнего ключа другой таблицы.
4. Нормализация
Нормализация – это процесс, позволяющий гарантировать эффективность структур данных в реляционной базе данных.
Первая нормальная форма требует, чтобы все значения полей были атомарными и все записи уникальными. Реляционная модель представленная на рисунке 3.1 находится в первой нормальной форме.
Модель находится во второй нормальной форме, если она, во-первых, находиться в первой нормальной форме; и, во-вторых, не содержит не ключевых атрибутов, находящихся в частичной функциональной зависимости от первичного ключа. Исходя из определения, разбиваем таблицу “поставщики” на две таблицы, вторую образовавшеюся таблицу назовем “данные поставщика”. В таблице “поставщики ” у нас остался только один идентификатор “идентификационный номер поставщика ” значит не ключевые атрибуты зависят, от всего первичного ключа. В таблице “ данные поставщика” нет не ключевых атрибутов, значит частичной зависимости быть не может. Таким же образом разбиваем таблицы “детали”, “проект”, “служащие”, и “заказ”. Реляционная модель во второй нормальной форме представлена на рисунке 4.1.
Модель находится в третьей нормальной форме, если она находится во второй нормальной форме и не имеет транзитивных зависимостей. Транзитивная зависимость – это зависимость между не ключевыми атрибутами. Таким образом, выделяем из таблицы “служащие” не ключевые атрибуты “должность” и “обязанности служащих”, которые находятся в зависимости, в отдельную таблицу “дополнительные сведения”. Получаем модель в третьей нормальной форме, которая представлена на рисунке 4.2.
Рисунок 4.1 – Вторая нормальная форма
Рисунок 4.2 – Третья нормальная форма
5. Проектирование базы данных в ACCESS.
Microsoft Access – это СУБД предназначенная для хранения и поиска информации, её представления в удобном виде и автоматизации часто повторяющихся операций. Чтобы реализовать базу данных в Access надо ввести через режим конструктора свою модель. Для начала надо ввести название таблиц и всех их атрибутов. Здесь же задается тип данных и первичный ключ.
Затем реализуем реляционную модель третей нормальной формы в схеме данных.
После этого вводим в таблицы данные и делаем запросы. Для этого создаем запросы через режим конструктора: добавляем нужные таблицы (связи выставим сами) и указываем поля, необходимые отобразить после запроса.
В результате на экран выведутся те поля, которые были указаны в запросе.
Можно создавать запросы с условиями отбора, или сортируя данные. К примеру, можно вывести всех поставщиков, фамилии которых начинаются на букву “М”. Для этого вводим отбор в графу “Условие отбора”. В результате появиться таблица, которая выводит всех поставщиков начинающееся на букву “М”.
6. Создание SQL запросов
Это - язык, который дает вам возможность создавать и работать в реляционных базах данных, содержащиеся в базе, управлять ими и налагать правила, обеспечивающие целостность реляционных данных, которые являются наборами связанной информации сохраняемой в таблицах.
Чтобы войти в режим SQL в access нужно в поле конструктора запроса нажать правой кнопкой и в появившемся окне нажать “Режим SQL”.
В появившемся окне прописываем SQL запрос. К примеру, нам надо показать какие данные находятся в таблице “Заказ”. Прописываем:
SELECT Заказ.id_z, Заказ.id_d, Заказ.id_s
FROM Заказ;
В итоге появится таблица “Заказ” в которой мы видим “номер заказа”, “номер деталей”, “номера служащих” и их содержимое.
Если нам надо в таблице “Детали” упорядочить “маркировку деталей” по возрастанию, то в окне SQL. Прописываем:
SELECT Детали.Название, Детали.Размер, Детали.Маркировка
FROM Детали
ORDER BY Детали.Маркировка;
В итоге появится таблица “Детали” в которой мы видим, что в графе “Маркировка” все поля упорядочены по возрастанию.
Если нам надо выяснить какие проекты были изготовлены с 01.01.93 по 01.01.95, то в окне SQL. Прописываем:
SELECT Проект.Название, Проект.id_r, Проект.[Дата Изготовления]
FROM Проект
WHERE (((Проект.[Дата Изготовления])>"01.01.92"));
В итоге появится таблица “Проект” в которой мы увидим, что в нем находятся проекты которые были изготовлены с 01.01.93 по 01.01.95
Если нам надо выяснить всех поставщиков на букву “М” то в окне SQL. Прописываем:
SELECT Поставщик.[Ф И О], Поставщик.id_p, Поставщик.Адрес
FROM Поставщик
WHERE (((Поставщик.[Ф И О]) Like "М*"));
То в итоге мы получим таблицу “Поставщики” где будут все поставщики начинающееся на букву “М”.
Если нам надо выяснить данные поставщика, то в окне SQL. Прописываем:
SELECT [Данные поставщика].*
FROM [Данные поставщика];
То в итоги мы получим таблицу “Данные поставщика” где мы увидим идентификационный номер поставщика и его номер ИНН.
7. Заключение
В этой курсовой работе я провел исследования и проектирование базы данных “Проекты”, в разработанной базе можно хранить данные о проектах кем они были разработаны, кто поставлял детали и когда и многое другое для полноценной её работы на каком либо предприятии. Проектирование осуществлялось на построением концептуальной модели, разработкой на её основе реляционной модели и реализацией базы в Microsoft Access. В ходе работы были изучены и реализованы команды на выборку в SQL.
Список использованных источников
1 Ребекка М. Райордан Основы реляционных баз данных 2001г.
2 Трифонова Н.А., Прозорова С.С. Office для студента. 2004г.
3 Ролланд Ф.Д. Основные концепции баз данных. 2002г.
4 Карпова Т. Базы данных: модели, разработка, реализация, 2001.
|
