Проектування та розробка баз даних надходження й продажу товарів у магазині

Курсова робота

з предмету «Бази даних»

Проектування та розробка баз даних надходження й продажу товарів у магазині

Вступ

Мета цієї курсової роботи полягає у автоматизуванні процесу надходження та продажу товарів магазину за допомогою розробки баз даних. Кожен менеджер (продавець) розуміє важливість кожної хвилини роботи, яке необхідно витратити на максимізацію прибутку, а не на ведення певної «ручної» бухгалтерії.

Для реалізації нашого курсового проекту ми використаємо наступний життєвий цикл реалізації баз даних:

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

-       проведення системного аналізу предметної області;

-       концептуальне моделювання предметної області;

-       логічне та фізичне проектування.

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

1. Стратегія автоматизації предметної області

 

.1 Загальні положення

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

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

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

Основні результати цього етапу повинні включати:

-      визначення цілей і завдань автоматизації;

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

-       визначення границь системи, сфера застосування системи баз даних;

-       можлива архітектура системи;

-       вимоги до системи;

-       поетапний план розробки.

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

1.2 Мета, цілі та задачі створення бази даних

Головною стратегічною метою бази даних, що проектується, є автоматизація процесів обліку й обробки даних надходження й продажу товарів для творчості у магазині з ціллю зменшення часу на пошук товарів «вручну», виписування товарних чеків, ведення обліку товарів, що залишилися

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

Цілі створення баз даних є наступні:

- Ефективний розподіл робочого часу працівників магазину.

-       Легкість в формуванні розрахунково-касових документів.

-       Швидкий пошук наявності необхідного товару.

-       Відображення повної характеристики товару.

-       Автоматизація подання звітів керівництву.

Досягнення зазначених цілей виконується за рахунок:

-      створення комплексної інформаційної системи із централізованою базою даних;

-       підвищення оперативності збору, обробки й надання необхідної інформації;

-       підвищення ефективності й продуктивності роботи обслуговуючого персоналу;

-       підвищення вірогідності, несуперечності, повноти й надійності інформації;

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

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

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

1.3 Вимоги до інформаційного забезпечення

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

-      систему класифікації і кодування;

-       поза - машинну інформаційну базу (ІБ);

-       внутрішньо - машинну ІБ.

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

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

Проектні рішення з розробки внутрішньо - машинної ІБ повинні відображати фізичний рівень зберігання інформації в системі у вигляді баз даних (БД) і масивів повнотекстової інформації і ураховувати:

-      розподілене збереження інформаційних ресурсів;

-       динаміку актуалізації інформації;

-       спосіб представлення та структуризацію інформації (реляційні БД, текстові файли, електронні документи і т. ін.).

БД має містити наступну інформацію:

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

-       БД постачальників: назва, розрахункові рахунки, юридична адреса, фізична адреса.

-       БД клієнтів магазину: П.І.Б., телефон.

-       БД виробників: назва, місто виробництва.

-       БД персоналу магазину: П.І.Б., посада

-       БД проданих товарів: товар, клієнт, продавець, дата.

-       БД видів творчості: назва, вид, товари для даного типу творчості

БД повинна бути спроектована таким чином, щоб задовольняти вимогам щодо реакції системи на запити. Для персоналу задовільним є 1-3 секунди.

Інформаційне забезпечення повинно задовольняти вимозі швидкого складання необхідних звітів. Звіти повинні складатися згідно до встановленим вихідним формам. Мова опису інформаційних запитів та опису вихідних документів (звітів, повідомлень та інше) повинна бути максимально простою.

2. Аналіз предметної області

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для обслуговування клієнтів на касі необхідно забезпечити менеджерів/продавців автоматизованою системою яка буде включати у себе бази даних товарів магазину та клієнтів. Та представити автоматизовані форми для видання товарних чеків покупцям.

Для формування звітності керівництву необхідно сформулювати бази даних звітів за день, місяць, рік.

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

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

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

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

Зв'язок - це будь-яка пойменована асоціація двох сутностей.

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

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

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

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

2.3.1 Сутність Товар

Короткий опис сутності: основна сутність на якій базуються інші і навколо якої будується уся автоматизована система.

Атрибути:

- номер;

-       назва;

-       вид;

-       одиниця виміру;

-       призначення(вид творчості);

-       виробник;

-       постачальник;

-       місце знаходження у магазині.

Зв’язки з сутностями.

- Товар може передбачати виробництво одного чи більше виробників;

-       Товар обов’язково відповідає одному і тільки одному місцю знаходженню у магазині;

-       Товар обов’язково відповідає одному і тільки одному виду товарів;

-       Товар обов’язково відповідає одній і тільки одній одиниці виміру;

-       Товар може передбачати належність до різних видів творчочті.

-       Товар може передбачати закупівлю у одного чи більше постачальників.

Бізнес-правила: номер товару унікально ідентифікує його, так як не можуть бути два і більше товари з однаковим номером. Усі інші атрибути товару є обов’язковими.

2.3.2 Сутність Вид

Короткий опис сутності: забезпечує розподіл товарів на категорії (наприклад, вид товару краски та вид товару пензлі).

Атрибути:

- номер;

-       назва;

-       опис.

Зв’язки з сутностями.

- Вид обов’язково відповідає одній і тільки одній назві.

Бізнес-правила: номер виду унікально ідентифікує його, так як не можуть бути два і більше видів товарів з однаковим номером. Усі інші атрибути видів товару є обов’язковими.

2.3.3 Сутність Виробник

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

Атрибути:

- номер;

-       назва;

-       країна виробника.

Зв’язки з сутностями.

- Виробник може відповідати одному чи більше товару.

Бізнес-правила: виробник визначається у відповідності з товаром, номер виробника унікально ідентифікує його, так як не можуть бути два і більше виробника товарів з однаковим номером. Усі інші атрибути є обов’язковими.

2.3.4 Сутність Постачальник

Короткий опис сутності: забезпечує можливість керівнику магазину прослідити ціни на один і той же товар у різних постачальників,(наприклад, краски можуть у виробника 1 коштувати 2 грн., а у виробника 2 - 4 грн.).

Атрибути:

- номер;

-       назва;

-       розрахунковий рахунок;

-       юридична адреса;

-       фізична адреса.

Зв’язки з сутностями.

- Постачальник може відповідати одному чи більше товару.

-       Постачальник обов’язково відповідає одному і тільки одному розрахунковому рахунку;

-       Постачальник обов’язково відповідає одній і тільки одній юридичній адресі;

-       Постачальник може відповідати одній чи більше фізичній адресі.

Бізнес-правила: постачальник визначається у відповідності з товаром, номер постачальника унікально ідентифікує його, так як не можуть бути два і більше постачальника товарів з однаковим номером. Усі інші атрибути є обов’язковими.

2.3.5 Сутність Покупець

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

Атрибути:

- П.І.Б.;

-       Телефон.

Зв’язки з сутностями.

- Покупець може відповідати одному чи більше товару.

-       Покупець обов’язково відповідає одному і тільки одному телефону;

Бізнес-правила: телефон покупця унікально ідентифікує його, так як не можуть бути два і більше покупця з однаковим номером телефону. Усі інші атрибути є обов’язковими.

2.3.6 Сутність Продавець

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

Атрибути:

- Номер;

-       П.І.Б.;

-       Адреса;

-       Паспортні данні.

Зв’язки з сутностями.

- Продавець обов’язково відповідає одному і тільки одному телефону;

-       Продавець обов’язково відповідає одній і тільки одній адресі;

-       Продавець обов’язково відповідає одним і тільки одним паспортним даним.

Бізнес-правила: номер персоналу унікально ідентифікує його, так як не можуть бути два і більше співробітника з однаковим номером. Усі інші атрибути є обов’язковими.

2.3.7 Сутність Чек

Короткий опис сутності: дає можливість керівнику продивлятися усі операції продажу за день, місяць,рік.

Атрибути:

- Номер;

-       Дата;

-       Покупець;

-       Товар;

-       Кількість;

-       Сума;

-       Продавець.

Зв’язки з сутностями.

- Звіт може відповідати одній чи більше даті.

-       Звіт може відповідати одному чи більше покупцеві.

-       Звіт може відповідати одному чи більше товару.

-       Звіт може відповідати одному чи більше товару.

Бізнес-правила: номер звіту унікально ідентифікує його, так як не можуть бути два і більше звіта з однаковим номером. Усі інші атрибути є обов’язковими.

3. Концептуальне моделювання предметної області

 

.1 Теоретичні положення концептуального моделювання

база дані товар магазин

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

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

Властивостями концептуальної моделі є наступні.

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

-       Вона включає тільки концептуально релевантні аспекти ПО, крім, таким чином, БУДЬ-ЯКИХ аспектів зовнішнього або внутрішнього представлення даних. Це означає, по перше, що концептуальна модель жодним чином не повинна фіксувати конкретні потреби окремих груп користувачів або додатків. Вона повинна фіксувати, що собою представляє ПО в цілому, а не з погляду інтересів або потреб користувачів. Вона повинна інтегрувати думки, погляди й інтереси окремих користувачів, але саме інтегрувати, для одержання цілісної картини, а не виражати їхні конкретні погляди, побажання думки. По-друге, у концептуальній моделі ПО ні яким чином не повинні відбиватися які-небудь аспекти майбутньої реалізації БД у комп'ютерному середовищі. Усе, що пов'язане з такими поняттями, як способи зберігання, методи доступу, ефективність виконання, оптимізація й т.д. перебувають за межами концептуальної моделі.

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

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

-                Централізоване адміністрування. Саме через концептуальну схему здійснюється адміністрування базами даних.

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

Ключовими результатами етапу концептуального моделювання э наступні:

- формальний опис інформаційного забезпечення предметної області.

-       докладний і строгий опис сховищ даних.

-       детальний опис потоків даних.

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

-       детальний опис діючих у предметній області правил і обмежень.

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

3.2 Мова ER-моделювання ПО

Мова ER-моделювання (Entity Relationship Modeling) - це мова визначення інформаційних потреб організації. Мова базується на концепції, відповідно до якої інформаційне забезпечення будь-якої предметної області представляється як сукупність взаємозалежних об'єктів. Процес моделювання полягає у виділенні сутностей ПО, установлення властивостей виділених сутностей і виявлення існуючих між ними зв'язків.

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

Розглянемо коротко основні властивості, формальні позначення й визначення сутностей, зв'язків, атрибутів.

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

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

-        ім'я;

-                ступінь/потужність;

-                факультативність - обов'язкова або факультативна.

Ці властивості використовуються для опису асоціації з кожної зі сторін, для завдання зв'язку повинні бути визначені обидва її кінця.

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

Рис. Приклад зв'язку

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

При читанні зв'язку з обов'язкової сторони перед її ім'ям використовуються слова "у всіх випадках" або "завжди"; для факультативної сторони використовуються слова "у загальному випадку" або "іноді". Ступінь "багато" читається як "один або декілька", а ступінь "один" - "один і тільки один".

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

Для подання атрибута пишеться його ім'я малими літерами в однині, можливо, із прикладами значень. Атрибути необов'язково показувати на діаграмі сутностей і зв'язків, однак додавання до сутності одного-двох атрибутів у період формування моделі, як правило, виявляється досить корисним.

Атрибут описує одну сутність. Атрибут повинен описувати ту сутність, до якої він віднесений. У кожний момент часу сутність може володіти лише одним значенням атрибута.

Атрибут, значення якого може бути відсутнім, називається факультативним. Він позначається символом "°" перед його ім'ям. Атрибут, значення якого повинне бути завжди відомо, називається обов'язковим, і позначається зірочкою "*" перед ім'ям. Обов'язковість означає, що сутність може бути визначена тоді й тільки тоді, коли відомі значення всіх її обов'язкових атрибутів. Всі атрибути унікального ідентифікатора повинні бути обов'язковими.

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

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

3.2 Побудова концептуальної моделі продажу товарів для продажу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблиця 1. Відношення сутності Товар

Ім’я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
TovNum	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Назва товару	Унікальний, обов’язковий
VudNum	ціле число	10	Зв’язок з видом товару	Зовнішній ключ, що посилається на первинний ключ відношення VUD. Обов’язковий
OdunNum	ціле число	10	Зв’язок з одиницею вимірювання	Зовнішній ключ, що посилається на первинний ключ відношення ODUN. Обов’язковий
NazNum	ціле число	10	Зв’язок з призначенням товару	Зовнішній ключ, що посилається на первинний ключ відношення NAZNACH. Обов’язковий
ProizNum	ціле число	10	Зв’язок з виробником товару	Зовнішній ключ, що посилається на первинний ключ відношення PROIZVOD. Обов’язковий
PostNum	ціле число	10	Зв’язок з постачальником товару	Зовнішній ключ, що посилається на первинний ключ відношення POSTACH. Обов’язковий
Misce	строка	20	Змістовний опис місця знаходження на полицях	Факультативний
Cina	Число	3,3	Ціна товару	Обов’язковий

Таблиця 2. Відношення сутності Вид

Ім’я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
VudNum	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Назва виду товару	Унікальний, обов’язковий	строка	40	Змістовний опис	Факультативний

Таблиця 3. Відношення сутності Виробник

Ім’я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
ProizNum	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Назва виробника	Унікальний, обов’язковий
Strana	строка	15	Країна виробник	Обов’язковий

Таблиця 4. Відношення сутності Постачальник

Ім’я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
PostNum	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Назва постачальника	Унікальний, обов’язковий
RR	ціле число	10	Розрахунковий рахунок	Обов’язковий
UrAdr	строка	40	Юридична адреса постачальника	Обов’язковий
FizAdr	строка	40	Фізична адреса постачальника	Обов’язковий

Таблиця 5. Відношення сутності Покупець

Ім’я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
PokNum	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Унікальний, обов’язковий
Tel	ціле число		Телефон покупця	Унікальний, обов’язковий

Таблиця 6. Відношення сутності Продавець

Ім’я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
ProdNum	ціле число	10	Унікальний ID	Первинний ключ
Name	строка	15	Призвище продавця	Унікальний, обов’язковий
Tel	ціле число	10	Телефон продавця	Унікальний, обов’язковий
Pasport	строка	8	Паспортні дані	Унікальний, обов’язковий
Adres	строка	25	Адреса продавця	Обов’язковий

Таблиця 7. Відношення сутності Звіт

Ім’я стовпця	Тип	Довжина	Призначення	Обмеження цілісності стовпців
ZvNum	ціле число	10	Унікальний ID	Первинний ключ
Date	дата		Дата проданного товару	обов’язковий
PokNum	ціле число	10	Зв’язок з покупцем	Зовнішній ключ, що посилається на первинний ключ відношення POKUP. Обов’язковий
TovNum	строка	40	Зв’язок з товаром	Зовнішній ключ, що посилається на первинний ключ відношення TOVAR. Обов’язковий
Kol	ціле число	10	Кількість купленого товару	обов’язковий
Sum	число	(3,3)	Сума купленного товару
ProdNum	Ціле число	10	Зв’язок зі спеціальністю	Зовнішній ключ, що посилається на первинний ключ відношення PROD. Обов’язковий

 

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

 

.2.1 Скрипти створення бази даних

Наведемо скрипт мови SQL Oracle, який створює таблиці БД.

/ AS SYSDBA

Створення таблиці VUDTABLE VUD ( integer        PRIMARY KEY, char(15)         UNIQUE NOT NULL,  varchar(40));

Створення таблиці PROIZVODTABLE PROIZVOD (        integer        PRIMARY KEY, char(15)      UNIQUE NOT NULL,  char(15)      NOT NULL);

Створення таблиці POSTACHTABLE POSTACH ( integer        PRIMARY KEY,         char(15)      UNIQUE NOT NULL,           integer        UNIQUE NOT NULL,         varchar(40) NOT NULL,        varchar(40) NOT NULL);

Створення таблиці POKUPTABLE POKUP (  integer        PRIMARY KEY, char(15)         UNIQUE NOT NULL,  integer        UNIQUE NOT NULL);

Створення таблиці PRODTABLE PROD (       integer        PRIMARY KEY, char(15)         UNIQUE NOT NULL,           integer        UNIQUE NOT NULL,  char(8)        UNIQUE NOT NULL,        varchar(25) NOT NULL);

Створення таблиці TOVARTABLE TOVAR ( integer        PRIMARY KEY, char(15)         UNIQUE NOT NULL,  integer        REFERENCES VUD(VudNum)               NOT NULL,        integer        REFERENCES ODUN(OdunNum)         NOT NULL,        integer         REFERENCES NAZNACH(NazNum)     NOT NULL,        integer        REFERENCES PROIZVOD(ProizNum)         NOT NULL,        integer        REFERENCES POSTACH(PostNum)   NOT NULL,        varchar(20),         number(3,3)         NOT NULL);

Створення таблиці ZVITTABLE ZVIT ( integer        PRIMARY KEY, date            NOT NULL,        integer        REFERENCES POKUP(PokNum)  NOT NULL,        integer         REFERENCES TOVAR(TovNum)          NOT NULL,                  integer        NOT NULL,                 number(3,3)         NOT NULL,        integer        REFERENCES PROD(ProdNum)         NOT NULL);

4.2.2 Інформаційно-пошукові запити

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

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

Заповнення таблиці VUD

INSERT INTO VUD VALUES (1, 'kraski', 'dlia risovaniya');INTO VUD VALUES (2, 'melki', 'dlia risovaniya');INTO VUD VALUES (3, 'karandashu', 'dlia risovaniya');INTO VUD VALUES (4, 'bysinu', 'dlia ykrasheniy');INTO VUD VALUES (5, 'bymaga', 'dlia risovaniya');

Заповнення таблиці ODUN

INSERT INTO ODUN  VALUES (1, 'sht');INTO ODUN     VALUES (2, 'ypakovka');

Заповнення таблиці NAZNACH

INSERT INTO NAZNACH   VALUES (1, 'skrap', 'skrapbyking');INTO NAZNACH         VALUES (2, 'plastik', 'plastikovue ykrasheniya');INTO NAZNACH      VALUES (3, 'lepka', 'lepim iz glinu');INTO NAZNACH         VALUES (4, 'risovanie', 'risyem');

Заповнення таблиці PROIZVOD

INSERT INTO PROIZVOD   VALUES (1, 'layra', 'kitai');INTO PROIZVOD  VALUES (2, 'puls', 'kitai');INTO PROIZVOD VALUES (3, 'amina', 'rossiya');INTO PROIZVOD         VALUES (4, 'moskva', 'rosiya');INTO PROIZVOD    VALUES (5, 'kurje', 'franciya');

Заповнення таблиці POSTACH

INSERT INTO POSTACH VALUES (1, 'lam1',253698745, 'ur 1', 'fiz 1');INTO POSTACH VALUES (2, 'lam2',248796314, 'ur 2', 'fiz 1');INTO POSTACH VALUES (3, 'lam3',148963245, 'ur 3', 'fiz 3');

Заповнення таблиці POKUP

INSERT INTO POKUP         VALUES (1, 'ivanov', 1453269);INTO POKUP         VALUES (2, 'petrov', 1452569);INTO POKUP VALUES (3, 'arikov', 1414969);INTO POKUP      VALUES (4, 'fastov', 1698269);

Заповнення таблиці PROD

INSERT INTO PROD VALUES (1, 'Psik',123456, '111111', 'adres 1');INTO PROD VALUES (2, 'Kyznec',123457, '222222', 'adres 2');

Заповнення таблиці TOVAR

INSERT INTO TOVAR VALUES (1, 'kraski belue', 1, 1, 4, 2, 1, 'ryaud 1', 20);INTO TOVAR VALUES (2, 'kraski zelenue', 1, 2, 4, 2, 1, 'ryaud 1', 25);INTO TOVAR VALUES (3, 'businki plastik', 4, 1, 2, 2, 1, 'ryaud 1', 20);

Запит 1.     Вивести усі стовбці таблиці VUD.

SELECT * FROM VUD;

Запит 2.     Вивести найменування товарів та їх вид творчості.

SELECT   TOVAR.Name, VUD.Name

FROM      TOVAR, VUD     VUD.VudNum = TOVAR.VudNum;

Висновки

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

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

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

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

Логічне та фізичне проектування БД складалося з конвертації концептуальної моделі ПО у реляційну модель даних. При цьому був використаний алгоритм конвертування схеми ПО у мові ER в схему реляційної бази даних. Після цього реляційна база даних була представлена у вигляді команд створення таблиць бази даних у мові SQL ORACLE. Крім того, у мові SQL описані деякі інформаційно-пошукові запити.

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

Список використаної літератури

1.      Інформатика: Комп’ютерна техніка. Комп’ютерні технології. Посіб./ За ред. О.І. Пушкаря - К.: Видав-ничий центр "Академія", 2011. - 696 с.

.        Жалдак М.І., Рамський Ю.С. Інформатика. - К.: "Вища школа", 2006. - с.

.        Бакаревич Ю.Б., Пушкина Н.В. Microsoft Access 2009. - СПб.:БХВ Санкт-Петербург, 1999.