Розробка бази даних складу

Системний аналіз предметної області. Загальні положення організації складу. Об'ємно-частотні характеристики даних. Інформаційно пошукові запити процесу керування складом. Логічне та фізичне проектування бази даних. Скрипти створення таблиць бази даних.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык украинский
Дата добавления 07.12.2012
Размер файла 205,0 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

ВСТУП

Метою курсової роботи, є створення бази даних складу. В базі враховані дані про сутності які опусують товари, складські приміщення, постачальників, замовників продукції зі складу, а також їхні платіжні реквізити, робітників складу, замовлення та типи товарів, техніку, термінали, та графік їх роботи. Також їхні звязки один з одним.

1. АНАЛІЗ ПРЕДМЕТНОЇ ОБЛАСТІ

1.1 Загальні положення системного аналізу ПО

Аналіз даних містить у собі документування всіх сутностей та атрибутів ПО. У ході даного етапу аналітики й користувачі працюють пліч-о-пліч, установлюючи й піддаючи скрупульозній перевірці вимоги, що деталізуються. У колективі повинна встановитися атмосфера впевненості в тому, що для визначення дійсних потреб і інтересів прикладної діяльності проаналізовані всі можливі аспекти, не упущена жодна деталь. Аналіз включає:

· проведення всіляких бесід з користувачами й узяття в них інтерв'ю;

· перегляд всіх циркулюючих в організації документів, бланків;

· аналіз потоку документів (документообіг);

· аналіз розв'язуваних в організації завдань і способів їхнього рішення;

· фіксація всіляких правил, обмежень, законів, що діють у ПО.

Факторами успіху проведення аналізу ПО є наступні:

· активна участь а проведенні аналізу не тільки системних аналітиків, а і всіх тих, хто буде використовувати розроблену систему;

· ретельна перевірка вірогідності, повноти, несуперечності отриманої інформації .

· виявлення всіх питань і припущень, що мають ключове значення для проектування й впровадження;

· точні об'ємно-частотні характеристики даних;

· твердий контроль за ходом робіт, повна концентрація зусиль на виконанні календарних планів і дотриманні запланованих строків.

1.2 Загальні положення організації складу

Склад це зазвичай велика інфраструктура яка складається з будівель де зберігаеться товар, техніки що працює на складі та людей які працюють на складі.

Техніка, термінали, співробітника мають кожен свій графік роботи від якого залежать підрахунки витрат на обслуговування техніки та виплата заробітної плати за відроблений час співробітникам складу.

Головною задачею складу являється зберігання та купівля і продаж товарів. При купілі чи продаажу товарв іншою стороною фінансових операцій по відношеню до складу являються контрагенти(замовники фбо постачальники) та мати платіжну нформацію про них. Товар відгружається через документ який має назву накладна, вона повина включати в себе назви товарів їх кількість, замовника або постачальника товарів, ціну замовлення та спіробітника(матеріально відповідальне обличе) складу який відповідає за прийом чи видачу товару.

Кожен товар ідентифікується за допомогою коду EAN13(European Article Number) - система кодування товару та виробника, та кодом товару в інвертарі складу та розпізнається за типом товару:

· Бакалія

· Хімія

· Техніка

· Одяг та взуття

· Парфумерія

· Овочі

· Фрукти

Також товар має ціну та число товарів які є в наявності.

1.3 Системний аналіз предметної області

Передбачається, що інформаційна модель ПО містить у собі бізнес правила, що діють у ПО й інформаційно-довідкові задачі. Саме ці три складові інформаційні моделі розкриваються далі. Крім того, інформаційна структура ПО описується з використанням наступних трьох понять: сутність, атрибут і зв'язок.

Тут під сутністю мається на увазі реальний або вигаданий об'єкт ПО, що становить самостійний інтерес із погляду інформаційної моделі ПО. Будь-яка сутність має унікальне в межах всієї ПО ім'я. Властивості сутності визначаються її атрибутами й зв'язками з іншими сутностями. Атрибут - це властивості, що характеризують сутність. Серед атрибутів (і/або, можливо, зв'язків) існує такий набір властивостей, які унікально ідентифікують будь-які екземпляри сутності. Виділяються обов'язкові й факультативні атрибути. Зв'язок - це будь-яка пойменована асоціація двох сутностей.

Бізнес-правила - це правила й обмеження, що діють у ПО відносно основних понять інформаційної структури (сутностей, атрибутів і зв'язків). Виділяються бізнес правила, що мають відносини до атрибутів однієї сутності (унікальність атрибутів, ідентифікація сутності, спеціальні правила, наприклад, тривалість практики вказується в годинниках і не повинна перевищувати 500 годин), до зв'язків між сутностями (факультативність закінчення зв'язку, потужність закінчень зв'язку (1:1, 1:n, m:n), ступінь зв'язку, наприклад, на факультеті повинне бути не більше 10 кафедр).

Інформаційно-довідкові задачі (на відміну від прикладних задач) -- це ті задачі, які вибирають деяку підмножину даних з інформаційної моделі ПО.

Далі предметна область описується із вказівкою сутностей їхніх атрибутів, зв'язків і діючий бізнес-правил. Опис інформаційно-довідкових задач приводиться окремо.

У результаті аналізу ПО були визначені наступні сутності, їх атрибути та зв'язки:

Сутність: ТОВАР

Короткий опис сутності. Це обєкт який купується або продається, що в даний час знаходить ся на складі

Атрибути. Сутність характеризується наступними атрибутами:

- Код товару

- Найменування товару

- Код EAN13

- Ціна

- Тип товару

- Місце зберігання

- Кількість

Зв'язки. Сутність ТОВАР має наступні зв'язки з іншими сутностями:

- ТОВАР обовязково повинен мати Тип товару

- ТОВАР обовязково повинен мати Місце зберігання

Бізнес-правила. ТОВАР унікально ідентифікується по коду EAN13 та кодом товару на складі, які у сукупності повині бути унікальними і обовязковими. Інші атрибути не унікальні.

Сутність: НАКЛАДНА

Короткий опис сутності. Cупроводний документ, що надається продавцем покупцеві і вміщує перелік товарів, їх кількість і ціну по якій вони будуть поставлені покупцеві, формальні особливості товару, зведення про відправника і одержувача.

Атрибути. Сутність характеризується наступними атрибутами:

- Номер накладної

- Вид накладної

- Контрагент

- Код товару

- Кількість товару

- Ціна товару

- Матеріално відповідальні обличе

Зв'язки. Сутність НАКЛАДНА має наступні зв'язки з іншими сутностями:

- НАКЛАДНА обов'язково повина мати Товар

- НАКЛАДНА обовязково повина мати Контрагента

- НАКЛАДНА обовязково повина мати Матеріально відповідальне обличе

Бізнес-правила. НАКЛАДНА унікально ідентифікується номером накладної, яка повинна бути унікальною і обов'язковою. Усі інші атрибути не унікальні.

Сутність: СКЛАД

Короткий опис сутності. Приміщеня де зберігаються товари

Атрибути. Сутність характеризується наступними атрибутами:

- Номер складу

- Місця зберігання

Зв'язки. Сутність СКЛАД має наступні зв'язки з іншими сутностями:

- СКЛАД обов'язково повинен мати Місця зберігання;

Бізнес-правила. СКЛАД унікально ідентифікується номером та кодом, які у сукупності повинні бути унікальним і обов'язковими. Усі інші атрибути не унікальні.

Сутність: МІСЦЕ ЗБЕРІГАННЯ

Короткий опис сутності. Нуероване місце в приміщені складу на якому зберігаються товари

Атрибути. Сутність характеризується наступними атрибутами:

- Номер місця

- Співробітник

- Товари

- Термінал

- Склад

Зв'язки. Сутність МІСЦЕ ЗБЕРІГАННЯ має такі зв'язків з іншими сутностями:

- МІСЦЕ обовязково повино мати Товар

- МІСЦЕ обовязково повино мати закріпленого за ним Співробітника

- МІСЦЕ обовязково має Термінали через які до нього є доступ

- МІСЦЕ обовязково має Склад на якому воно знаходиться

Бізнес-правила. МІСЦЕ ЗБЕРІГАННЯ унікально ідентифікується номером місця та складом , якиі повині бути унікальними і обов'язковими. Усі інші атрибути не унікальні.

Сутність:ТИП ТОВАРУ

Короткий опис сутності. Може приймати наступні значення:

· Бакалія

· Хімія

· Техніка

· Одяг та взуття

· Парфумерія

· Овочі

· Фрукти

Атрибути. Сутність характеризується наступними атрибутами:

- Код типу

- Опис типу

Зв'язки. Сутність ТИП ТОВАРУ не має зв'язків з іншими сутностями:

Бізнес-правила. ТИП ТОВАРУ ідентифікується кодом, який повинен бути унікальним і обов'язковими. Усі інші атрибути не унікальні.

Сутність: КОНТРАГЕНТ

Короткий опис сутності. Юридична особа яка є другою стороною фінансових операцій, по відношеню до складу це є замовники та постачальники продукції.

Атрибути. Сутність характеризується наступними атрибутами:

- Код Контрагента

- Найменування

- Платіжні реквізити

- Адреса

Зв'язки. Сутність КОНТРАГЕНТ має наступні зв'язки з іншими сутностями:

- КОНТРАГЕНТ обовязково повинен мати Платіжну інформацію

Бізнес-правила. КОНТРАГЕНТ унікально ідентифікується кодом, який повинен бути унікальним і обов'язковим. Усі інші атрибути не унікальні.

Сутність: ПЛАТІЖНА ІНФОРМАЦІЯ

Короткий опис сутності. Платіжні дані юридичних осіб.

Атрибути. Сутність характеризується наступними атрибутами:

- Код

- Номер платіжного рахунку

- Назва банку

- Адреса банку

Зв'язки. Сутність ПЛАТІЖНА ІНФОРМАЦІЯ не має зв'язки з іншими сутностями:

Бізнес-правила. ПЛАТІЖНА ІНФОРМАЦІЯ унікально ідентифікується кодом та номером платіжного рахунку, які повинні бути унікальними і обов'язковими.

Сутність: СПІВРОБІТНИК

Короткий опис сутності. Особа яка працює на складі.

Атрибути. Сутність характеризується наступними атрибутами:

- Код співробітника

- Імя

- Прізвище

- По батькові

- Графік роботи

- Місце роботи

- Техніка

Зв'язки. Сутність СПІВРОБІТНИК має такі зв'язків з іншими сутностями:

- СПІВРОБІТНИЕ обовязково має графік роботи

- СПІВРОБІТНИК може Місце роботи або Техніку за якими закріплений

Бізнес-правила. СПІВРОБІТНИК унікально ідентифікується кодом співробітника, який повиннен бути унікальними і обов'язковими.

Сутність: ГРАФІК РОБОТИ

Короткий опис сутності. Описує графік роботи спіробітників, техніки та терміналів

Атрибути. Сутність характеризується наступними атрибутами:

- Код граффіку

- Початок роботи

- Кінець роботи

Зв'язки. Сутність ГРАФІК РОБОТИ не має зв'язків з іншими сутностями.

Бізнес-правила. ГРАФІК РОБОТИ унікально ідентифікується кодом графіку, який повиннен бути унікальним і обов'язковим.

Сутність: ТЕХНІКА

Короткий опис сутності. Описує техніку яка працює на складі

Атрибути. Сутність характеризується наступними атрибутами:

- Реестраційний номер

- Тип техніки

- Графік роботи

- Співробітника

Зв'язки. Сутність ТЕХНІКА має такі зв'язки з іншими сутностями:

- ТЕХНІКА обовязково має графік роботи.

- ТЕХНІКА обовязково має Співробітника.

Бізнес-правила. ТЕХНІКА унікально ідентифікується Реестраційним номером, який повиннен бути унікальним і обов'язковим.

Сутність: ТЕРМІНАЛ

Короткий опис сутності. Термінал - це пункт видачі чи прийому товару на складі

Атрибути. Сутність характеризується наступними атрибутами:

- Номер терміналу

- Місця

- Графік роботи

Зв'язки. Сутність ТЕРМІНАЛ має такі зв'язки з іншими сутностями:

- ТЕРМІНАЛ обовязково має місця зберігання.

- ТЕРМІНАЛ обовязково має Графік роботи.

Бізнес-правила. ТЕРМІНАЛ унікально ідентифікується Номером терміналу, який повиннен бути унікальним і обов'язковим.

1.2 Інформаційно-довідкові задачі

Проведений аналіз предметної області дозволив виділити перелік сутностей, що беруть участь у ведені обліку та організації на складі. Аналіз цих сутностей та їх атрибутів, дозволяє виділити декілька класів типових інформаційно-довідкових задач.

По-перше, інформація, що пов'язана з відпуском та прийомом товарів:

· надання повної інформації по товарам, замовникам та накладним.

· надання інформації по видам, товарів.

По-друге, це інформація організаційного характеру:

· надання інформації про місце зберігання товарів (складм, місцям зберігання або терміналам через які є доступ до місць зберігання товарів).

По-третє, це інформація, що відноситься до процесу керування складом:

· надання інформації по співробітникам;

· техніці

· розпорядком роботи співробітникі та техніки

склад таблиця інформаційний

2. Логічне та фізичне проектування бази даних

Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.

Логічне проектування -- це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..

Фізичне проектування - це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.

2.1 Логічне проектування

У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.

Для перетворення концептуальної моделі, представленої у вигляді мови ER-моделювання, у реляційну модель, був використаний наступний алгоритм.

· Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім'я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.

· Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім'я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.

· Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.

Рис. Концептуальна ER-модель

Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов'язаний той або інший зв'язок.

· Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.

· Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE та NOT NULL.

Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.

В даній базі даних, міститься 11 таблиць. Далі в таблиці наведений опис кожної таблиці.

Ім'я стовпця

Тип

Довжина

Призначення

Обмеження цілісності стовпців

GOODS

Code

лічильник

Унікальне значення

Первинний ключ

Name

строка

50

Назва товару

Обов'язковий

EAN13

строка

50

Код EAN13 товару

Первиний ключ Обов'язковий

Унікальний

Cost

Дійсне число

Max,10

Ціна товару

TypeFK

Ціле число

Код типу товару

Обовязковий

Зовнішній ключ, що посилається на первинний ключ відношення GOODS_TYPE

StoringPlaceFK

Ціле число

Місце зберігання товару

Обовязковий

Зовнішній ключ, що посилається на первинний ключ відношення Storage

Number_of_units

Ціле число

Кількість одиниць товару в наявності

Обов'язковий

BILL

Number

лічильник

Унікальне значення

Первинний ключ

Обовязковий

Type

строка

Визначає тип накладної

Обов'язковий, може приймати значення: (ПОСТАВКА, ЗАМОВЛЕННЯ)

ContractorFK

ціле число

50

Код Контрагента

Зовнішній ключ, що посилається на первинний ключ відношення Contractor

Обовязковий

GoodsFK

ціле число

Код товару який внесенно до накладної

Зовнішній ключ, що посилається на первинний ключ відношення GOODS

Обовязковий

Number_of_units

ціле число

Кількість товарів

Обов'язковий

Cost

Дійсне число

Max,10

Ціна всіх товарів

Суммарна ціна всіх товарів

Financially_responsible_personFK

ціле число

Код Співробітника який є матеріально відповідальним за дану операцію

Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE

Обовязковий

WAREHOUSE

Num

лічильник

Унікальне значення

Первинний ключ

Обовязковий

StorageFK

ціле число

Номер місця зберігання

Обовязковий

Зовнішній ключ, що посилається на первинний ключ відношення STORAGE

GOODS_TYPE

TypeCode

лічильник

Унікальне значення

Первинний ключ

Обовязковий

Description

строка

50

Опис типу товару

Обовязковий

Може приймати тільки такі значення

· Бакалія

· Хімія

· Техніка

· Одяг та взуття

· Парфумерія

· Овочі

· Фрукти

STORAGE

StorageNum

лічильник

Унікальне значення

Первинний ключ. Обов'язковий

EmployeeFK

ціле число

Код співробітника закріпленого за місцем

Обов'язковий

Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE

GoodsFK

ціле число

Код товару який зберігається

Обов'язковий

Зовнішній ключ, що посилається на первинний ключ відношення GOODS

WarehouseFK

Ціле число

Код скалду на якому знаходиться

Обов'язковий

Зовнішній ключ, що посилається на первинний ключ відношення WAREHOUSE

TerminalFK

Циле число

Код терміналу через який є доступ до місця зберігання

Обов'язковий

Зовнішній ключ, що посилається на первинний ключ відношення TERMINAL

CONTRACTOR

Code

лічильник

Унікальне значення

Первинний ключ

Обовязковий

Name

ціле число

Назва контрагента

Первинний ключ Обов'язковий

Billing_infoFK

Ціле число

10

Платіжна інформація код платіжної інформації

Зовнішній ключ, що посилається на первинний ключ відношення BILLING_INFORMATION

Обов'язковий

Adress

строка

50

Адреса кконтрагента

BILLING_INFORMATION

Code

лічильник

Унікальне значення

Первинний ключ Обов'язковий

BankName

строка

50

Назва банку

Обов'язковий

Account_Number

строка

20

Номер рахунку

Унікальинй Обов'язковий

BankAdres

строка

20

Адреса банку

Обов'язковий

EMPLOYEE

Code

лічильник

Унікальне значення

Первинний ключ Обов'язковий

Name

строка

50

Імя спіробітника

Обов'язковий

Last_Name

Строка

50

Прізвище співробітника

Обов'язковий

Middle_Name

Строка

50

По батькові співробітника

Обов'язковий

ScheduleFK

Ціле число

Код графіку роботи

Зовнішній ключ, що посилається на первинний ключ відношення SCHEDULE

Обов'язковий

StorageNumFK

Ціле число

Номер місця зберігання

Зовнішній ключ, що посилається на первинний ключ відношення STORAGE

TechnicNumFK

Ціле число

Номер транспортного засобу

Зовнішній ключ, що посилається на первинний ключ відношення TECHNIC

SCHEDULE

Code

лічильник

Унікальне значення

Первинний ключ Обов'язковий

StartTime

Дата

Час початку роботи

Обов'язковий

EndTime

Дата

Час кінця роботи

Обов'язковий

TECHINC

Reg_number

лічильник

Унікальне значення

Первинний ключ Обов'язковий

Type

строка

50

Назва техніки

Обов'язковий

Може приймати значення

· Навантажувач

· Грузовий

· Кран

Schedule_CodeFK

Ціле число

Код графіку роботи

Обовязковий

Зовнішній ключ, що посилається на первинний ключ відношення SCHEDULE

Обов'язковий

Employee_CodeFK

Код співробітника

обовязковий

Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE

Обов'язковий

TERMINAL

Num

лічильник

Унікальне значення

Первинний ключ Обов'язковий

EmployeeFK

Ціле число

Код співробітника закріпленог о за місцем

Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE

Обов'язковий

ScheduleFK

Ціле число

Код графіку роботи

Обов'язковий

Зовнішній ключ, що посилається на первинний ключ відношення SCHEDULE

Обов'язковий

StorageFK

Ціле число

Місця в реміналі

Обов'язковий

Зовнішній ключ, що посилається на первинний ключ відношення STORAGE

Обов'язковий

2.2 Фізичне проектування

База даних спроектована для її збереження у СКБД Oracle, яка підтримує реляційну модель даних і є об'єкто-реляційною СКБД. Ця СКБД має дуже розвинені можливості по створенню та супроводу баз даних, оскільки володіє найбільш розвиненою системою типів даних, можливостями індексування полів, що дозволяє одержувати доступ до даних за мінімальний час, а також функціями по забезпеченню підтримки цілісності даних між реляційними таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачеві витрати на підтримку цілісності збережених даних і одержання даних з бази даних. Робота з базою даних підтримується за допомогою реляційної мови запитів SQL.

Логічна модель бази даних легко відображається в реляційну фізичну модель, оскільки логічна модель була побудована з використанням реляційної структури даних. Крім того, логічна модель була приведена у третю нормальну форму, тому усі відношення представляються у фізичній моделі окремими таблицями. Ніякі злиття відношень в одну таблицю для підвищення ефективності виконання окремих класів запитів не виконуються у зв'язку з тим, що такі класи запитів не були знайдені. У результаті отримано сімнадцять таблиць реляційної бази даних, де кожне відношення прямо відповідає окремій таблиці, атрибути кожного відношення стають полями цієї таблиці, а первинні ключі відношень стають первинними ключами таблиць.

2.3 Скрипти створення таблиць бази даних

Створення таблиці ТОВАР:

create table GOODS

(

Code integer UNIQUE NOT NULL ,

Name varchar2(50) NOT NULL,

EAN13 varchar2(50) constaraint goods_eqn_uniq UNIQUE NOT NULL,

Cost number(MAX,10) ,

TypeFK integer constaraint goods_goodsType_frk references GOODS_TYPE(TypeCode) NOT NULL,

StoringPlaceFK integer constaraint goods_storage_frk refernces STORAGE(StorageNum) NOT NULL,

Number_of_units integer NOT NULL

Constraint goods_pk primary key(Code,EAN13)

);

Сторення таблиці НАКЛАДНА:

Create table BILL

(

Number integer constarint bill_pk primary key,

Type varchar2(20) constarint bill_type_chk check (Type in(`supply','order')) NOT NULL,

ContractorFK integer constarint bill_contractor_frk references CONTRACTOR(Code) NOT NULL,

GoodsFK integer constaraint bill_goods_frk references GOODS(Code) NOT NULL,

Number_of_units integer NOT NULL,

Cost number(MAX,10) NOT NULL,

Financially_responsible_personFK integer constarint bill_employee_frk references EMPLOYEE(Code) NOT NULL;

);

Створення таблиці СКЛАД:

Create table WAREHOUSE

(

Num integer constarint warehosue_prk primary key,

StorageFK integer constarint warehouse_storage_frk references SOTRAGE(StorageNum) NOT NULL

);

Створення таблиці МІСЦЕ ЗБЕРІГАННЯ:

Create table SORAGE

(

StorageNum integer constarint storage_prk primary key,

EmployeeFK integer constarint storage_employee_frk references EMPLOYEE(Code) NOT NULL,

GoodsFK intger constarint storage_goods_frk references GOODS(Code) NOT NULL,

WarehouseFK integer constarint storage_warehouse_frk references WAREHOUSE(Num) NOT NULL,

TerminalFK integer constarint storage_terminal_frk references TERMINAL(Num) NOT NULL

);

Створення таблиці ТИП ТОВАРУ:

Create table GOODS_TYPE

(

TypeCode integer constarint goods_type_prk primary key,

Description varchar2(50) constarint goods_type_desc_chk check (Description in (`Grocery', `Chemistry', `Engineering', `Clothing and footwear', `Perfumes','Vegetables',' Fruits')) NOT NULL

);

Створення таблиці ПЛАТІЖНА ІНФОРМАЦІЯ:

Create table BILLING_INFORMATION

(

Code integer constarint billing_information_prk primary key,

BankName varchar2(50) NOT NULL,

Account_Number varchar2(50) constraint bl_accnum_unq UNIQUE NOT NULL,

BankAddress varchar2(50) NOT NULL

);

Створення таблиці КОНТРАГЕНТ:

Ctreate table CONTRACTOR

(

Code integer constraint contractor_prk primary key,

Name varcahr2(50) NOT NULL,

Billing_infoFK integer constraint contractor_billing_info_frk references BILLING_INFORMATION(Code) NOT NULL,

Address varchar2(50) NOT NULL

);

Створення таблиці ТЕРМІНАЛ:

Create table TERMINAL

(

Num integer constraint terminal_prk primarykey,

EmployeeFK integer constraint terminal_employee_frk references EMPLOYEE(Code) NOT NULL,

ScheduleFK integer constraint terminal_schedule_frk references SCHEDULE(Code) NOT NULL,

StorageFK integer constraint terminal_storage_frk references STORAGE(Num) NOT NULL

);

Створення таблиці ГРАФІК РОБОТИ:

Create table SCHEDULE

(

Code integer constraint schedule_prk primary key,

StartTime date NOT NULL,

EndTime date NOT NULL

);

Створення таблиці ТЕХНІКА:

Create table TECHNIC

(

Reg_number integer constraint techinic_prk primary key,

Type varchar2(50) constraint techinic_type_chk check(Type in(`Wheel', `Freight', `Crane')) NOT NULL,

Schedule_CodeFK integer constraint technic_schedule_frk references SCHEDULE(Code) NOT NULL,

Employee_CodeFK integer constraint technic_employee_frk references EMPLOYEE(Code) NOT NULL

);

Стоврення таблиці СПІВРОБІТНИК:

Create table EMPLOYEE

(

Code integer constraint employee_prk primary key,

Name varchar2(50) NOT NULL,

Last_Name varchar2(50) NOT NULL,

Middle_Name varchar2(50) NOT NULL,

ScheduleFK integer constraint employee_schedule_frk references SCHEDULE(Code) NOT NULL,

StorageNumFK integer constraint employee_storage_frk references STORAGE(Num),

TechnicNumFK integer constraint employee_technic_frk references TECHNIC(Reg_number)

);

3. Створення запитів до бази даних

Наведемо приклади інформаційно пошукових запитів відносно тих задач, які були окреслені в підрозділі «1.4. Інформаційно-довідкові задачі». Приклади наведемо у мові SQL Oracle з використанням бази даних, визначеної у попередньому підрозділі.

3.1 Інформаційно-пошукові запити повязані з товарами та накладними

Запит 1. Вивести перелік товарів та їх видів товарів, які входять в накладну з номером 1

SELECT g.Name, t.Description

FROM GOODS_TYPE t, GOODS g, BILL b

WHERE g.TypeFK = t.Code AND b.GoodsFK = g.Code AND b.Number =

1ORDER BY g.Name, t.Description;

Запит 2. Вивести номер Накладних де матеріально відповідальним обличем є Іванов

SELECT b.Number as “BILL NNUMBER”, e.LastName as “F.R.P.”

FROM EMPLOYEE e, BILL b

WHERE b. Financially_responsible_personFK = e.Code AND e.LastName

= `Іванов' ORDER BY b.Number, e.LastName;

Запит 3. Вивести імя контрагента де замовлення на товар Банани первищює 100 одиниць

SELECT c.Name

FROM BILL b, CONTRACTOR c,GOODS g

WHERE c.Code = b.ContractorFK AND b.GoodsFK = g.Code AND g.Name= `Банани' AND b. Number_of_units > 100

ORDER BY c.Name;

3.2 Інформаційно пошукові запити організаційного характеру

Запит 1. Вивести номер складу де зберігаються Телевізори та вивести їх кільксіть

SELECT w.Num as “WAREHOUSE”, g. Number_of_units as “Count”

FROM WAREHOUSE w , STORAGE s, GOODS g

WHERE w.StorageFK = s.StorageNum AND s.GoodsFK = g.Code AND g.Name = `Телевізор'

ORDER BY w.Num, g.Number_of_units;

Запит 2. Вивести номери терміналів складу номер 1

SELECT w.Num as “WAREHOUSE”, have' t.Num as “TERMINALS”

FROM WAREHOUSE w , STORAGE s, TERMINAL t

WHERE w.StorageFK = s.StorageNum AND s.TerminalFK = t.Num AND w.Num = 1

ORDER BY w.Num, t.Num;

Запит 3. Вивести час початку роботи терміналів які мають доступ до місця зберігання номер 2

SELECT sc.StartTime , s.Num

FROM STORAGE s, TERMINAL t,SCHEDULE sc

WHERE s.TerminalFK = t.Num AND t.ScheduleFK = sc.Code AND s.Num = 2 ORDER BY sc.StartTime, s.Num

3.3 Інформаційно пошукові запити процесу керування складом

Запит 1. Вивести Прізвища співробітників та тип техніки яка за ними закріплена

SELECT e.Last_Name, t.Type

FROM EMPLOYEE e, TECHNIC t

WHERE t.EmployeeFK = e.Code

ORDER BY e.LastName, t.Type;

Запит 2. Вивести Графік роботи терміналів які мають місця зберігання за якими закріплений співробітник іванов

SELECT she.StartTime , she.EndTime

FROM EMPLOYEE e, TRMINAL t,SCHEDULE she,STORAGE s

WHERE s.EmployeeFK = e.Code AND t.StorageFK = s.Num AND t.ShceduleFK = she.Code AND e.Last_Name = `Ivanov'

ORDER BY she.StartTime , she.EndTime;

Запит 3. Вивести Графік роботи співробітників

SELECT e.Last_Name, she.StartTime , she.EndTime

FROM EMPLOYEE e,SCHEDULE she

WHERE e.ScheduleFK = she.Code

ORDER BY she.StartTime , she.EndTime;

ВИСНОВОК

Проектування баз даних -- це складний, багатокроковий процес перетворення інформаційного середовища ПЗ у інформаційну модель у вигляді бази даних.

Цей процес складається з різних етапів, а саме: аналіз ПЗ, побудова концептуальної моделі ПЗ, логічне та фізичне проектування БД.

На сучасному етапі розвитку інформатики проектування баз даних перетворилося на цілком сформовану наукову дисципліну, яка має у своєму складі формально-теоретичну та технологічну складові.

Теоретичної основою проектування баз даних є теорія нормалізації, яка дозволяє чітко і строго відповісти на таке запитання: як слід проводити перетворення початкової схеми ПЗ таким чином, щоб результуюча схема бази даних була еквівалентна початковій і була краща за неї. Методологія проектування детально описує усі етапи життєвого циклу створення бази даних з використанням сучасних мов опису ПЗ.

Ціллю курсової роботи було проектування бази даних обліку складу.

Була побудована концептуальна модель. Для цього була використана мова ER-опису ПЗ, яка базується на концепції, що інформаційна модель будь-якої ПЗ може бути описана із застосування таких понять, як сутність, атрибут, зв'язок. Крім того, ця мова є суттєво графічною, що дає можливість наочно представляти концептуальну модель ПЗ.

При побудові концептуальної моделі неявно використовувалися результати теорії нормалізації. Необхідності використання більш високих нормальних форм не було, так як у предметній області не були виявлені складні види транзитивних функціональних залежностей, а також багатозначні залежності.

Реляційна база даних була представлена у вигляді команд створення таблиць бази даних у мові SQL ORACLE. Крім того, у мові SQL описані деякі інформаційно-пошукові запити.

Виконана курсова робота надала мені можливості ознайомитися з технологією проектування баз даних, та отримати практичний досвід у проектуванні бази даних з конкретної предметної області.

Размещено на Allbest.ru


Подобные документы

  • Систематизація знань як основна функція бази даних. Логічне та фізичне проектування бази даних. Створення таблиць у базі даних, визначення основних зв'язків. Інструментальні засоби проектування та створення програмного забезпечення для обробки даних.

    курсовая работа [1,4 M], добавлен 29.04.2010

  • Основні відомості про реляційні бази даних, система управління ними. Основні директиви для роботи в середовищі MySQ. Визначення та опис предметної області. Створення таблиць та запитів бази даних автоматизованої бази даних реєстратури в поліклініці.

    курсовая работа [2,9 M], добавлен 06.11.2011

  • Розробка структури бази даних. ER-моделі предметної області. Проектування нормалізованих відношень. Розробка форм, запитів, звітів бази даних "Автосалон". Тестування роботи бази даних. Демонстрація коректної роботи форми "Додавання даних про покупців".

    курсовая работа [4,0 M], добавлен 02.12.2014

  • Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.

    курсовая работа [8,8 M], добавлен 16.12.2015

  • Проектування бази даних, що реалізує звіти про графік робіт на об’єктах впродовж місяця. Графічне зображення нагромаджувачів даних. Побудова діаграм потоків даних і переходів станів, таблиць у вигляді двовимірного масиву, запитів. Створення бази даних.

    курсовая работа [1,2 M], добавлен 29.02.2012

  • Проектування і реалізація реляційної бази даних для централізованого зберігання інформації з метою полегшення і систематизації даних замовлень клієнтів готельного комплексу. Розробка сценаріїв для створення бази даних і базових таблиць проекту.

    курсовая работа [147,2 K], добавлен 02.06.2019

  • Розробка бази даних для меблевої фірми. Обстеження і аналіз предметної області та побудова концептуальної, логічної та фізичної моделі цієї бази даних. Використання мови програмування Visual Basic при написанні програмного коду, що обслуговує базу даних.

    курсовая работа [1,4 M], добавлен 24.10.2010

  • Аналіз предметної галузі, постановка задачі, проектування бази даних. UML-моделювання, побудова ER-діаграми, схеми реляційної бази даних у третій нормальній формі. Призначення і логічна структура. Опис фізичної моделі бази даних, програмної реалізації.

    курсовая работа [3,5 M], добавлен 28.11.2011

  • Узагальнена структурна схема інформаційної системи та алгоритми її роботи. Проект бази даних. Інфологічне проектування і дослідження предметної області. Розробка інфологічної моделі предметної області. Розробка композиційної, логічної системи бази даних.

    курсовая работа [861,7 K], добавлен 21.02.2010

  • Аналіз предметної області, проектування бази даних, її фізичної реалізації в СУБД Access. Схема даних зі зв'язками між таблицями. Форми, що забезпечують інтерфейс. Запити у режимі Конструктора і мовою SQL. Звіти в режимі звіту і в режимі Конструктора.

    курсовая работа [5,2 M], добавлен 01.04.2016

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.