Федеральне агентство з освіти
МІНІСТЕРСТВО ОСВІТИ УНІВЕРСИТЕТ СИСТЕМ УПРАВЛІННЯ ТА РАДІОЕЛЕКТРОНІКИ (ТУСУР)
Кафедра комплексної інформаційної безпеки електронних обчислювальних систем
(КІБЕВС)
Проектування навчально-дослідної бази даних
"Накладні"
Пояснювальна записка до курсової роботи з дисципліни
«Бази даних»
Студент гр. 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.
МІНІСТЕРСТВО ОСВІТИ УНІВЕРСИТЕТ СИСТЕМ УПРАВЛІННЯ ТА РАДІОЕЛЕКТРОНІКИ (ТУСУР)
Кафедра комплексної інформаційної безпеки електронних обчислювальних систем
(КІБЕВС)
Проектування навчально-дослідної бази даних
"Накладні"
Пояснювальна записка до курсової роботи з дисципліни
«Бази даних»
Студент гр. 523-3
____________ Н.В. Власов
«___»_______________
Керівник курсової роботи
_____________ М. А. Сопів
«___»_______________
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. Побудова реляційної моделі
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.