Федеральне агентство з освіти
МІНІСТЕРСТВО ОСВІТИ УНІВЕРСИТЕТ СИСТЕМ УПРАВЛІННЯ ТА РАДІОЕЛЕКТРОНІКИ (ТУСУР)
Кафедра комплексної інформаційної безпеки електронних обчислювальних систем
(КІБЕВС)
СТВОРЕННЯ БАЗИ ДАНИХ ДЛЯ НАКЛАДНОЇ
Пояснювальна записка до курсової роботи.
2006
Федеральне агентство з освіти
МІНІСТЕРСТВО ОСВІТИ УНІВЕРСИТЕТ СИСТЕМ УПРАВЛІННЯ ТА РАДІОЕЛЕКТРОНІКИ (ТУСУР)
Кафедра комплексної інформаційної безпеки електронних обчислювальних систем (КІБЕВС)
ЗАВДАННЯ
Необхідно створити базу даних паспортно-візової служби. Дослідити задану предметну область, вибрати істотні атрибути. Побудувати концептуальну модель предметної області.
На основі концептуальної моделі побудувати реляційну модель, встановити зв'язки між об'єктами. Поставити первинні та зовнішні ключі. Провести нормалізацію. Пояснити виконані перетворення.
Провести дослідження отриманої моделі, задавши кілька складних запитів до отриманої моделі.
Дата видачі завдання: "____"_______ 2006
Завдання прийнято до виконання
«____» ___________ 2006р. Підпис студента___________
Зміст
Введення
1. Побудова концептуальної моделі
2. Побудова реляційної моделі
3. Нормалізація
4. Проектування бази даних в ACCESS
5. Створення SQL запитів
Висновок
Список використаних джерел
Введення
Система з базою даних - це будь-яка інформаційна система на базі комп'ютера, в якій дані можуть спільно використовуватися багатьма програмами. Це означає, що дані організовані таким чином, щоб підтримувати не тільки одне конкретне застосування. Основна відмінність системи з базою даних від традиційної файлової системи - це багаторазове і різноманітне використання одних і тих же даних. Дані не прив'язані до якогось конкретного додатком і не контролюється ним. Окремі програми більше не відповідають за створення і ведення даних. Ці обов'язки покладаються на нижележащий рівень програмного забезпечення - систему управління базою даних (СКБД). СУБД виконує роль посередника між користувачами додатків і даними. Також СУБД повинна забезпечувати гарантії безпеки і цілісності бази даних. Користувачі комп'ютера повинні мати можливість захистити свої дані від несанкціонованого доступу, а також відновити їх у разі якихось системних збоїв. Централізоване забезпечення безпеки даних - важлива особливість СУБД. Найбільш значну перевагу систем з базами даних - це централізоване забезпечення цілісності даних.
1. Побудова концептуальної моделі
При вивченні баз даних найважливіше значення має їх проектування. Побудова концептуальної моделі являє собою процес моделювання смислового наповнення бази даних. Концептуальна модель складається з наступних трьох основних компонентів.
1 Сутності. Це елементи реального світу, які можуть існувати незалежно. У моєму випадку предикатами є: магазин, продавець, накладна, центр. офіс. Сутність представляється у концептуальній моделі прямокутником, в якому зазначено її ім'я.
2 Атрибути. Вони описують сутність. Атрибути представляються овалами з зазначенням імен, які прикріплені до сутності. У моєму випадку магазину відповідають: телефон, товари, назва, адреса. Продавцю відповідають: ПІБ, №, телефон, магазин, адреса. Центр. Офісу відповідають: адреса, телефон, назву. Накладної відповідають: сума, №, ким видана, дата видачі, податок, вид товару, в якій магазин.
3 Зв'язки. Зв'язок представляє взаємодію між сутностями. На діаграмі вона зображується ромбом, який з'єднує сутності, які беруть участь у зв'язку. У моєму випадку зв'язок між паспортистів та документами буде один до багатьох, так як конкретний пакет документів обслуговує один паспортист, який у свою чергу обробляє довільну кількість документів. Всі інші зв'язки будуть один до одного, оскільки кожному громадянину відповідає свій пакет документів, кожного набору документів відповідає один паспорт РФ і один закордонний паспорт.
На малюнку 2.1 представлена концептуальна модель заданої бази даних.
SHAPE \ * MERGEFORMAT
Малюнок 2.1 - Концептуальна модель
2. Побудова реляційної моделі
В даний час переважає технологія реляційних баз даних. Вона забезпечує відносно прості засоби представлення даних і маніпулювання ними. У реляційній базі даних всі дані зберігаються в таблицях. Назви сутностей стануть заголовками таблиць, а атрибути стануть стовпцями. Цілісність даних в реляційної базі даних грунтується на концепції ключів. Первинний ключ (PK) - це атрибут який можна використовувати для унікальної ідентифікації таблиці. Так у таблиці "магазин" первинним ключем стане "id_M", у таблиці "продавець" - "id-P", у таблиці "накладна" - "id_N", таблиця "центр.офіс" буде ідентифікуватися атрибутом "id_C". Зовнішній ключ (FK) - це атрибут, який існує в кількох таблицях і є первинним ключем однієї з цих таблиць. Зв'язок проводимо від первинного ключа одою таблиці до зовнішнього ключа іншої таблиці. Реляційна модель представлена на малюнку 3.1.
SHAPE \ * MERGEFORMAT
Малюнок 3.1-Реляційна модель
3. Нормалізація
Нормалізація - це процес, який дозволяє гарантувати ефективність структур даних в реляційній базі даних.
Перша нормальна форма вимагає, щоб всі значення полів були атомарними і всі записи унікальними. Реляційна модель представлена на малюнку 3.1 знаходиться в першій нормальній формі.
Модель знаходиться в другій нормальній формі, якщо вона, по-перше, перебувати в першій нормальній формі, і, по-друге, не містить неключових атрибутів, що знаходяться в частковій функціональної залежності від первинного ключа. Виходячи з визначення, розбиваємо таблицю "продавець" на дві таблиці, Друге утворилося таблицю назвемо "дані продавця". У таблиці "продавець" у нас залишився лише один код "id_P" означає неключові атрибути залежать від усього первинного ключа. У таблиці "дані продавця" немає неключових атрибутів, значить часткової залежності бути не може. Таким же чином розбиваємо таблиці "магазин", "накладна" і "центр офіс". Реляційна модель в другій нормальній формі представлена на малюнку 4.1.
Модель знаходиться в третій нормальній формі, якщо вона знаходиться в другій нормальній формі і не має транзитивних залежностей. Транзитивне залежність - це залежність між неключових атрибутами. Таким чином, виділяємо з таблиці "продавець" неключові атрибути "телефон" і "адреса", які знаходяться в залежності, в окрему таблицю "опис продавця". Отримуємо модель в третій нормальній формі, яка представлена на малюнку 4.2.
Малюнок 4.1 - Друга нормальна форма
Малюнок 4.2 - Третя нормальна форма
4. Проектування бази даних у ACCESS.
Microsoft Access - це СУБД призначена для зберігання і пошуку інформації, її представлення у зручному вигляді та автоматизації часто повторюваних операцій (рис. 5.1). Щоб реалізувати базу даних у access треба ввести через режим конструктора свою модель. Для початку треба ввести назву таблиць і всіх їх атрибутів. Тут же задається тип даних і первинний ключ (рис. 5.2).
Малюнок 5.1 - Таблиці в access
Малюнок 5.2 - атрибути таблиці "Накладна"
Потім реалізуємо свою реляційну модель третин нормальної форми в схемі даних (рис. 5.3).
Малюнок 5.3 - схема даних
Після цього вводимо в таблиці дані і робимо запити. Для цього створюємо запити через режим конструктора: додаємо потрібні таблиці (зв'язку виставляються самі) і вказуємо поля, необхідні відобразити після
запиту (рис. 5.4).
Малюнок 5.4 - Створення запиту
У результаті на екран виведуться ті поля, які були вказані в запиті (рис. 5.5).
Малюнок 5.5 - Результат запиту
Можна створювати запити з умовами відбору, або сортуючи дані. Наприклад, потрібно вивести товари, податок на які перевищує 5000. Для цього вводимо обмеження в графу "Умова відбору" (рис. 5.6).
У результаті з'явитися таблиця з товарами податок на які 8448 і 9844. (Рис. 5.7).
Малюнок 5.6 - Введення обмеження
Малюнок 5.7 - Результат запиту
5. Створення SQL запитів
SQL - це мова реляційних баз даних, що дозволяє користувачеві створювати і видаляти дані, що містяться в базі, управляти ними і накладати правила, що забезпечують цілісність реляційних даних. Щоб увійти в режим SQL в access потрібно в полі конструктора запиту натиснути правою кнопкою і у вікні натиснути "Режим SQL" (рис. 6.1).
Малюнок 6.1 - Вибір режиму SQL
У вікні пишемо запит і вибірку, враховуючи синтаксис. Наприклад, треба відсортувати номери телефонів продавців за зростанням (рис. 6.2). Прописуємо:
SELECT [визначення продавця]. Адреса, [визначення продавця]. Телефон
FROM [визначення продавця]
ORDER BY [визначення продавця]. Телефон;
Оператор SELECT створює необхідну таблицю, за допомогою FROM перераховуються таблиці, які містять необхідні для виконання запиту дані, FROM - оператор сортування за зростанням. Цей запит можна описати так: створити таблицю зі стовпцями "адреса" і "телефон", сортуючи таблицю "телефон" за зростанням.
У результаті з'явиться таблиця з телефонами розташованими у порядку зростання (рис. 6.3).
Малюнок 6.2 - запит SQL в access
Малюнок 6.3 - Результат запиту
Уявімо ще декілька запитів, створених за допомогою SQL.
Наступний запит виводить поля: "id_M", "кількість на складі", "товари" з таблиці "товари магазину" і відбирає всі товари, що починаються на букву "п".
SELECT [товари магазину]. Id_M, [товари магазину]. [Кількість на складі], [товари магазину]. Товари
FROM [товари магазину]
WHERE ((([товари магазину]. Товари) Like "п *"));
Наступний запит виводить поля: "id_N" і "№" з таблиці "дані накладної" і відбирає номери накладних більше 700.
SELECT [дані накладної]. Id_N, [дані накладної]. №
FROM [дані накладної]
WHERE ((([дані накладної]. №)> "700"));
Наступний запит виводить поля: "податок" і "в який магазин" з таблиці "накладна" і відбирає магазини у яких податок більше 3000 і назва закінчується на 2.
SELECT Накладная.налог, Накладна. [В який магазин]
FROM Накладна
WHERE (((Накладная.налог)> "3000") AND ((Накладная. [в який магазин]) Like "* 2"));
Висновок
У цьому звіті представлено роботу з дослідження й проектування бази даних для паспортно-візової служби, в отриманій базі можна зберігати дані про клієнтів і співробітників паспортного столу. Проектування представлено побудовою концептуальної моделі, розробкою на її основі реляційної моделі і реалізацією бази в Microsoft Access. У ході роботи були вивчені і реалізовані команди на вибірку в SQL.
Список використаних джерел
1. Ролланд Ф.Д. Основні концепції баз даних. 2002р.
2. Трифонова Н.А., Прозорова С.С. Office для студента. 2004р.
МІНІСТЕРСТВО ОСВІТИ УНІВЕРСИТЕТ СИСТЕМ УПРАВЛІННЯ ТА РАДІОЕЛЕКТРОНІКИ (ТУСУР)
Кафедра комплексної інформаційної безпеки електронних обчислювальних систем
(КІБЕВС)
СТВОРЕННЯ БАЗИ ДАНИХ ДЛЯ НАКЛАДНОЇ
Пояснювальна записка до курсової роботи.
|
2006
Федеральне агентство з освіти
МІНІСТЕРСТВО ОСВІТИ УНІВЕРСИТЕТ СИСТЕМ УПРАВЛІННЯ ТА РАДІОЕЛЕКТРОНІКИ (ТУСУР)
Кафедра комплексної інформаційної безпеки електронних обчислювальних систем (КІБЕВС)
ЗАВДАННЯ
Необхідно створити базу даних паспортно-візової служби. Дослідити задану предметну область, вибрати істотні атрибути. Побудувати концептуальну модель предметної області.
На основі концептуальної моделі побудувати реляційну модель, встановити зв'язки між об'єктами. Поставити первинні та зовнішні ключі. Провести нормалізацію. Пояснити виконані перетворення.
Провести дослідження отриманої моделі, задавши кілька складних запитів до отриманої моделі.
Дата видачі завдання: "____"_______ 2006
Завдання прийнято до виконання
«____» ___________ 2006р. Підпис студента___________
Зміст
Введення
1. Побудова концептуальної моделі
2. Побудова реляційної моделі
3. Нормалізація
4. Проектування бази даних в ACCESS
5. Створення SQL запитів
Висновок
Список використаних джерел
Введення
Система з базою даних - це будь-яка інформаційна система на базі комп'ютера, в якій дані можуть спільно використовуватися багатьма програмами. Це означає, що дані організовані таким чином, щоб підтримувати не тільки одне конкретне застосування. Основна відмінність системи з базою даних від традиційної файлової системи - це багаторазове і різноманітне використання одних і тих же даних. Дані не прив'язані до якогось конкретного додатком і не контролюється ним. Окремі програми більше не відповідають за створення і ведення даних. Ці обов'язки покладаються на нижележащий рівень програмного забезпечення - систему управління базою даних (СКБД). СУБД виконує роль посередника між користувачами додатків і даними. Також СУБД повинна забезпечувати гарантії безпеки і цілісності бази даних. Користувачі комп'ютера повинні мати можливість захистити свої дані від несанкціонованого доступу, а також відновити їх у разі якихось системних збоїв. Централізоване забезпечення безпеки даних - важлива особливість СУБД. Найбільш значну перевагу систем з базами даних - це централізоване забезпечення цілісності даних.
1. Побудова концептуальної моделі
При вивченні баз даних найважливіше значення має їх проектування. Побудова концептуальної моделі являє собою процес моделювання смислового наповнення бази даних. Концептуальна модель складається з наступних трьох основних компонентів.
1 Сутності. Це елементи реального світу, які можуть існувати незалежно. У моєму випадку предикатами є: магазин, продавець, накладна, центр. офіс. Сутність представляється у концептуальній моделі прямокутником, в якому зазначено її ім'я.
2 Атрибути. Вони описують сутність. Атрибути представляються овалами з зазначенням імен, які прикріплені до сутності. У моєму випадку магазину відповідають: телефон, товари, назва, адреса. Продавцю відповідають: ПІБ, №, телефон, магазин, адреса. Центр. Офісу відповідають: адреса, телефон, назву. Накладної відповідають: сума, №, ким видана, дата видачі, податок, вид товару, в якій магазин.
3 Зв'язки. Зв'язок представляє взаємодію між сутностями. На діаграмі вона зображується ромбом, який з'єднує сутності, які беруть участь у зв'язку. У моєму випадку зв'язок між паспортистів та документами буде один до багатьох, так як конкретний пакет документів обслуговує один паспортист, який у свою чергу обробляє довільну кількість документів. Всі інші зв'язки будуть один до одного, оскільки кожному громадянину відповідає свій пакет документів, кожного набору документів відповідає один паспорт РФ і один закордонний паспорт.
На малюнку 2.1 представлена концептуальна модель заданої бази даних.
SHAPE \ * MERGEFORMAT
продавець |
Особистий номер |
ПІБ |
ПІБ |
магазин |
Центр. офіс |
телефон |
адреса |
магазин |
телефон |
адреса |
накладна |
податок |
Дата видачі |
ким видана |
Номер накладної |
У який магазин |
Малюнок 2.1 - Концептуальна модель
2. Побудова реляційної моделі
В даний час переважає технологія реляційних баз даних. Вона забезпечує відносно прості засоби представлення даних і маніпулювання ними. У реляційній базі даних всі дані зберігаються в таблицях. Назви сутностей стануть заголовками таблиць, а атрибути стануть стовпцями. Цілісність даних в реляційної базі даних грунтується на концепції ключів. Первинний ключ (PK) - це атрибут який можна використовувати для унікальної ідентифікації таблиці. Так у таблиці "магазин" первинним ключем стане "id_M", у таблиці "продавець" - "id-P", у таблиці "накладна" - "id_N", таблиця "центр.офіс" буде ідентифікуватися атрибутом "id_C". Зовнішній ключ (FK) - це атрибут, який існує в кількох таблицях і є первинним ключем однієї з цих таблиць. Зв'язок проводимо від первинного ключа одою таблиці до зовнішнього ключа іншої таблиці. Реляційна модель представлена на малюнку 3.1.
SHAPE \ * MERGEFORMAT
Id_P (PK) ПІБ Особистий номер Телефон Магазин адреса |
Продавець |
Id_M (PK) ПІБ Адреса ІПН Id_P (FK) |
Магазин |
Накладна |
Id_N (PK) Сума Номер накладної Ким видана Дата видачі Податок Вид товару У який магазин Id_C (FK) |
Центр. офіс |
Продавець-Накладна |
Id_N (FK) Id_P (FK) |
Малюнок 3.1-Реляційна модель
3. Нормалізація
Нормалізація - це процес, який дозволяє гарантувати ефективність структур даних в реляційній базі даних.
Перша нормальна форма вимагає, щоб всі значення полів були атомарними і всі записи унікальними. Реляційна модель представлена на малюнку 3.1 знаходиться в першій нормальній формі.
Модель знаходиться в другій нормальній формі, якщо вона, по-перше, перебувати в першій нормальній формі, і, по-друге, не містить неключових атрибутів, що знаходяться в частковій функціональної залежності від первинного ключа. Виходячи з визначення, розбиваємо таблицю "продавець" на дві таблиці, Друге утворилося таблицю назвемо "дані продавця". У таблиці "продавець" у нас залишився лише один код "id_P" означає неключові атрибути залежать від усього первинного ключа. У таблиці "дані продавця" немає неключових атрибутів, значить часткової залежності бути не може. Таким же чином розбиваємо таблиці "магазин", "накладна" і "центр офіс". Реляційна модель в другій нормальній формі представлена на малюнку 4.1.
Модель знаходиться в третій нормальній формі, якщо вона знаходиться в другій нормальній формі і не має транзитивних залежностей. Транзитивне залежність - це залежність між неключових атрибутами. Таким чином, виділяємо з таблиці "продавець" неключові атрибути "телефон" і "адреса", які знаходяться в залежності, в окрему таблицю "опис продавця". Отримуємо модель в третій нормальній формі, яка представлена на малюнку 4.2.
Id_P (PK) ПІБ Особистий номер Телефон Магазин адреса |
Продавець |
Id_M (PK) ПІБ Адреса ІПН Id_P (FK) |
Магазин |
Накладна |
Центр. офіс |
Продавець-Накладна |
Id_N (FK) Id_P (FK) |
Id_C (PK) Адреса Телефон Назва |
Id_P (FK) № |
Id_N (FK) № |
Дані продавця |
Дані-Накладний |
Дані магазину |
Дані центр.офіса |
Id_М (FK) назва телефон |
Id_С (FK) назва |
Id_N (PK) Сума Номер накладної Ким видана Дата видачі Податок Вид товару У якій магазин Id_C (FK) |
Малюнок 4.2 - Третя нормальна форма
Id_P (PK) ПІБ Особистий номер Телефон Магазин адреса |
Продавець |
Id_M (PK) ПІБ Адреса ІПН Id_P (FK) |
Магазин |
Накладна |
Центр. офіс |
Продавець-Накладна |
Id_N (FK) Id_P (FK) |
Id_C (PK) Адреса Телефон Назва |
Id_P (FK) № |
Id_N (FK) № |
Дані продавця |
Дані-Накладний |
Дані магазину |
Дані центр.офіса |
Id_М (FK) назва телефон |
Id_С (FK) назва |
Id_N (PK) Сума Номер накладної Ким видана Дата видачі Податок Вид товару У якій магазин Id_C (FK) |
Телефон Адреса (FK) |
Опис продавця |
4. Проектування бази даних у ACCESS.
Microsoft Access - це СУБД призначена для зберігання і пошуку інформації, її представлення у зручному вигляді та автоматизації часто повторюваних операцій (рис. 5.1). Щоб реалізувати базу даних у access треба ввести через режим конструктора свою модель. Для початку треба ввести назву таблиць і всіх їх атрибутів. Тут же задається тип даних і первинний ключ (рис. 5.2).
Малюнок 5.1 - Таблиці в access
Малюнок 5.2 - атрибути таблиці "Накладна"
Потім реалізуємо свою реляційну модель третин нормальної форми в схемі даних (рис. 5.3).
Малюнок 5.3 - схема даних
Після цього вводимо в таблиці дані і робимо запити. Для цього створюємо запити через режим конструктора: додаємо потрібні таблиці (зв'язку виставляються самі) і вказуємо поля, необхідні відобразити після
запиту (рис. 5.4).
Малюнок 5.4 - Створення запиту
У результаті на екран виведуться ті поля, які були вказані в запиті (рис. 5.5).
Малюнок 5.5 - Результат запиту
Можна створювати запити з умовами відбору, або сортуючи дані. Наприклад, потрібно вивести товари, податок на які перевищує 5000. Для цього вводимо обмеження в графу "Умова відбору" (рис. 5.6).
У результаті з'явитися таблиця з товарами податок на які 8448 і 9844. (Рис. 5.7).
Малюнок 5.6 - Введення обмеження
Малюнок 5.7 - Результат запиту
5. Створення SQL запитів
SQL - це мова реляційних баз даних, що дозволяє користувачеві створювати і видаляти дані, що містяться в базі, управляти ними і накладати правила, що забезпечують цілісність реляційних даних. Щоб увійти в режим SQL в access потрібно в полі конструктора запиту натиснути правою кнопкою і у вікні натиснути "Режим SQL" (рис. 6.1).
Малюнок 6.1 - Вибір режиму SQL
У вікні пишемо запит і вибірку, враховуючи синтаксис. Наприклад, треба відсортувати номери телефонів продавців за зростанням (рис. 6.2). Прописуємо:
SELECT [визначення продавця]. Адреса, [визначення продавця]. Телефон
FROM [визначення продавця]
ORDER BY [визначення продавця]. Телефон;
Оператор SELECT створює необхідну таблицю, за допомогою FROM перераховуються таблиці, які містять необхідні для виконання запиту дані, FROM - оператор сортування за зростанням. Цей запит можна описати так: створити таблицю зі стовпцями "адреса" і "телефон", сортуючи таблицю "телефон" за зростанням.
У результаті з'явиться таблиця з телефонами розташованими у порядку зростання (рис. 6.3).
Малюнок 6.2 - запит SQL в access
Малюнок 6.3 - Результат запиту
Уявімо ще декілька запитів, створених за допомогою SQL.
Наступний запит виводить поля: "id_M", "кількість на складі", "товари" з таблиці "товари магазину" і відбирає всі товари, що починаються на букву "п".
SELECT [товари магазину]. Id_M, [товари магазину]. [Кількість на складі], [товари магазину]. Товари
FROM [товари магазину]
WHERE ((([товари магазину]. Товари) Like "п *"));
Наступний запит виводить поля: "id_N" і "№" з таблиці "дані накладної" і відбирає номери накладних більше 700.
SELECT [дані накладної]. Id_N, [дані накладної]. №
FROM [дані накладної]
WHERE ((([дані накладної]. №)> "700"));
Наступний запит виводить поля: "податок" і "в який магазин" з таблиці "накладна" і відбирає магазини у яких податок більше 3000 і назва закінчується на 2.
SELECT Накладная.налог, Накладна. [В який магазин]
FROM Накладна
WHERE (((Накладная.налог)> "3000") AND ((Накладная. [в який магазин]) Like "* 2"));
Висновок
У цьому звіті представлено роботу з дослідження й проектування бази даних для паспортно-візової служби, в отриманій базі можна зберігати дані про клієнтів і співробітників паспортного столу. Проектування представлено побудовою концептуальної моделі, розробкою на її основі реляційної моделі і реалізацією бази в Microsoft Access. У ході роботи були вивчені і реалізовані команди на вибірку в SQL.
Список використаних джерел
1. Ролланд Ф.Д. Основні концепції баз даних. 2002р.
2. Трифонова Н.А., Прозорова С.С. Office для студента. 2004р.