Формування меню установи громадського харчування
Вступ
інформаційний меню логічний
Мета цього курсового проекту полягає у розробці
бази даних предметної області, яка має відношення до формування меню установи
громадського харчування. У загальному випадку створення будь-якої програмної
системи, у тому числі і бази даних, проходить складний життєвий цикл. Існує
багато методологій по опису життєвого циклу проектування та розробки баз даних.
У цьому курсовому проекті буде використано методологію, згідно з якою життєвий
цикл складається з наступних етапів:
· розробка стратегії автоматизації
предметної області;
· проведення системного
аналізу предметної області;
· концептуальне моделювання
предметної області;
· логічне та фізичне
проектування.
Як відомо, усяка предметна область складається з
двох компонентів: переліку задач, які повинні автоматизуватися, та інформації,
на основі якої задачі вирішуються. Приймаючи до уваги, що курсовий проект має
відношення до проблематики баз даних, ми опишемо усі ці етапи не по відношенню
до всієї предметної області, а тільки до її інформаційної моделі.
Головною ціллю курсового проекту є проектування
бази даних меню установи громадського харчування.
1. Стратегія автоматизації предметної області
.1 Загальні положення
Метою етапу стратегії є формування разом з
керівництвом замовника безлічі прикладних моделей, визначення переліку
рекомендацій і прийняття погодженого плану розробки системи, складеного з
урахуванням наявних організаційних, фінансових і технічних обмежень і що
відбиває як поточні, так і перспективні потреби організації. Крім того, на
етапі розробки стратегії автоматизації повинні бути сформульовані основі цілі
автоматизації.
Крім того, ця початкова робота повинна
забезпечити створення погодженої стабільної основи, що виділяє найбільш важливі
ділянки робіт на різних етапах розробок проектів у міру їхнього проходження
через стадії аналізу, проектування, реалізації, документування, досвідченого
впровадження й промислової експлуатації.
Повний детальний аналіз організації дає основу
для розвитку перспективного плану створення системи. Визначення стратегії
інформатизації здійснюється проведенням повного, однак узагальненого аналізу,
на підставі якого потім будується великомасштабна модель прикладної області.
Стратегія повинна визначатися в досить стислий термін для того, щоб не втрачати
актуальності результатів.
Основні результати цього етапу повинні включати:
· визначення цілей і завдань автоматизації;
· визначення напрямку
прикладної діяльності, наприклад, мети й завдання прикладної діяльності,
пріоритети, обмеження, критичні фактори успіху, ключові показники ефективності;
· визначення границь
системи, сфера застосування системи баз даних;
· можлива архітектура
системи;
· вимоги до системи;
· поетапний план розробки.
У курсовому проекту на етапі розробки стратегії
ми опишемо тільки мету та цілі автоматизації, а також деякі вимоги по
створюваної бази даних.
.2 Мета, цілі та задачі створення бази даних
Головною стратегічною метою бази даних, що
проектується, є автоматизація процесу формування довгострокового зберігання й
обробки даних, що мають міститись в меню установи громадського харчування з
метою задоволення інформаційних потреб співробітників установи, що мають
відношення до формування даного меню.
Система повинна будуватися таким чином, щоб у
міру можливостей вона була інформаційно-сумісна з іншими системами, що мають
відношення до роботи установ громадського харчування.
Мета автоматизації - зняти частину роботи з
відповідальних за меню працівників, забезпечити більш легкий доступ до
інформації.
Треба визнати, що в майбутньому, електронні
документи витіснять паперові, тому що вони більш задовільні за такими
критеріями як вартість, поновлення, швидкість передачі. Тому необхідно
забезпечити максимально зручний доступ користувачів до інформації бази даних.
Цілями створення бази даних є наступні:
· Підвищення ефективності й продуктивності
планування меню установи громадського харчування.
· Спрощення операції
внесення змін в меню, наявні страви або напої.
· Оперативне надання повної
й несуперечливої інформації про страви та напої, що присутні в меню.
Використання ДБ надає можливість отримання інформації, яка містить чіткі та
найповніші дані про продукти, що використовуються в стравах. Несуперечливість
даних досягається за рахунок обмежень бізнес-правилами, які закладені в БД.
· Оперативне додавання
інформації про поточні акції та позначок до страв або напоїв, що є акційними
пропозиціями.
· Групування позицій меню в
відповідності до певних спільних характеристик.
Досягнення зазначених цілей виконується за
рахунок:
· створення комплексної інформаційної
системи із централізованою базою даних;
· підвищення оперативності
збору, обробки й надання необхідної інформації;
· підвищення ефективності й
продуктивності роботи обслуговуючого персоналу;
· підвищення вірогідності,
несуперечності, повноти й надійності інформації;
· підвищення наочності,
зручності використання й інформативності одержуваних даних;
· надання доступу всім
зацікавленим особам до всіх інформаційно-обчислювальних ресурсів;
· автоматизації
інформаційного пошуку, одержання інформації безпосередньо на робочих місцях.
.3 Вимоги до інформаційного забезпечення
Проектні рішення з інформаційного забезпечення
(ІЗ) повинні передбачати реалізацію концепції «відкритих систем», тобто
розширення функціональних можливостей системи без зміни існуючих елементів ІЗ.
ІЗ повинно задовольняти умові можливої повноти. Інформаційне забезпечення
системи повинно включати:
· систему класифікації і кодування;
· поза машинну інформаційну
базу (ІБ);
· внутрішньо-машинну ІБ.
Система класифікації і кодування повинна
забезпечувати оптимальний процес накопичення і зберігання інформації, а також
вирішення функціональних задач з мінімальними витратами пам`яті і максимальною
швидкодією.
Поза-машинна ІБ повинна розроблятися з
урахуванням існуючого документообігу і відображати сукупність вхідних та
вихідних документів та повідомлень, що призначені для обміну інформацією між
користувачами та засобами автоматизації системи. Формати вихідних документів
повинні відповідати найбільш поширеним форматам представлення документації.
Поза-машинна ІБ може містити методики формування описів інформаційних ресурсів
та самі інформаційні ресурси на зовнішніх носіях, що підготовлені за цими
методиками.
Проектні рішення з розробки внутрішньо-машинної
ІБ повинні відображати фізичний рівень зберігання інформації в системі у
вигляді баз даних (БД) і масивів повнотекстової інформації і ураховувати:
· розподілене збереження інформаційних
ресурсів;
· динаміку актуалізації
інформації;
· спосіб представлення та
структуризацію інформації (реляційні БД, текстові файли, електронні документи і
т. ін.).
БД має містити наступну інформацію:
· Загальна інформація про кожну страву або
напій. Вона містить назву, склад, опис, рекомендований напій (для страв),
вагу(об’єм), акцію, вартість та
спосіб подачі.
· Інформація про
інгредієнти. Містить назву та одиниці виміру.
· Інформація поточні акції
установи громадського харчування. Містить назву акції та умови її проведення.
· Інформація про групи
страв(напоїв). Містить назви груп страв для зручнішої організації даних.
БД повинна бути спроектована таким чином, щоб
задовольняти вимогам щодо реакції системи на запити. Для диспетчера задовільним
є 1-3 секунди, а для інших користувачів бази даних 1-5 секунд.
Інформаційне забезпечення повинно задовольняти
вимозі швидкого складання необхідних звітів. Звіти повинні складатися згідно до
встановленим вихідним формам. Мова опису інформаційних запитів та опису
вихідних документів (меню, звіти) повинна бути максимально простою.
2. Аналіз предметної області
.1 Загальні положення системного аналізу ПО
Підсумки етапу розробки стратегії слугують
вихідною базою для проведення досліджень на етапі аналізу, де вони проходять
ретельну перевірку, уточнюються й деталізуються до такого рівня, щоб
забезпечити необхідний ступінь адекватності моделювання прикладної області,
гарантувати реалізацію рішень і сформувати тверду основу для проведення етапу
проектування.
Аналіз даних містить у собі документування всіх
сутностей та атрибутів ПО. У ході даного етапу аналітики й користувачі працюють
пліч-о-пліч, установлюючи й піддаючи скрупульозній перевірці вимоги, що
деталізуються. У колективі повинна встановитися атмосфера впевненості в тому,
що для визначення дійсних потреб і інтересів прикладної діяльності
проаналізовані всі можливі аспекти, не упущена жодна деталь. Аналіз включає:
· проведення всіляких бесід з користувачами
й узяття в них інтерв'ю;
· перегляд всіх циркулюючих
в організації документів, бланків;
· аналіз потоку документів
(документообіг);
· аналіз розв'язуваних в
організації завдань і способів їхнього рішення;
· фіксація всіляких правил,
обмежень, законів, що діють у ПО.
Факторами успіху проведення аналізу ПО є
наступні:
· активна участь а проведенні аналізу не
тільки системних аналітиків, а і всіх тих, хто буде використовувати розроблену
систему;
· ретельна перевірка
вірогідності, повноти, несуперечності отриманої інформації.
· виявлення всіх питань і
припущень, що мають ключове значення для проектування й впровадження;
· точні об'ємно-частотні
характеристики даних;
· твердий контроль за ходом
робіт, повна концентрація зусиль на виконанні календарних планів і дотриманні
запланованих строків.
.2 Загальні положення формування меню установи громадського
харчування
Меню - перелік страв і напоїв, що подаються в кафе, ресторані
або барі. У ресторані, меню являє собою презентацію пропонованих страв і
напоїв.
Процес формування меню є важливою частиною
управління будь-якою установою громадського харчування. Метою цього процесу є
найбільш зручна для відвідувачів та адміністрації організація інформації про
страви та напої, що є в асортименті.
Організація меню передбачає розбиття всіх страв
та напоїв на групи, виходячи з певних загальних характеристик, що вони мають
(гарячі страви, салати, закуски, алкогольні напої, соки тощо).
Часто установи громадського харчування проводять
акції. При формуванні меню зазвичай роблять помітки про це на сторінці зі
стравою або напоєм, що приймає участь в акції.
Додавання нової страви або нового напою в меню
передбачає формування складу страви(напою), створення опису, формування
вартості.
.3 Системний аналіз предметної області
Передбачається, що інформаційна модель ПО містить
у собі інформаційну структуру ПО, бізнес правила, що діють у ПО й
інформаційно-довідкові задачі. Саме ці три складові інформаційні моделі
розкриваються далі. Крім того, інформаційна структура ПО описується з
використанням наступних трьох понять: сутність, атрибут і зв'язок.
Тут під сутністю мається на увазі реальний
або вигаданий об'єкт ПО, що становить самостійний інтерес із погляду
інформаційної моделі ПО. Будь-яка сутність має унікальне в межах всієї ПО ім'я.
Властивості сутності визначаються її атрибутами й зв'язками з іншими
сутностями. Атрибут - це властивості, що характеризують сутність. Серед
атрибутів (і/або, можливо, зв'язків) існує такий набір властивостей, які
унікально ідентифікують будь-які екземпляри сутності. Виділяються обов'язкові
й факультативні атрибути. Зв'язок - це будь-яка пойменована
асоціація двох сутностей.
Бізнес-правила - це правила й
обмеження, що діють у ПО відносно основних понять інформаційної структури
(сутностей, атрибутів і зв'язків). Виділяються бізнес правила, що мають відносини
до атрибутів однієї сутності (унікальність атрибутів, ідентифікація сутності,
спеціальні правила, наприклад, вартість вказується в грошових одиницях і не
повинна бути від’ємною), до зв'язків між сутностями (факультативність
закінчення зв'язку, потужність закінчень зв'язку (1:1, 1:n, m:n), ступінь
зв'язку, наприклад, страва не може приймати участь більше, ніж в одній акції.
Інформаційно-довідкові задачі (на відміну від
прикладних задач) - це ті задачі, які вибирають деяку підмножину даних з
інформаційної моделі ПО.
Далі предметна область описується із вказівкою
сутностей їхніх атрибутів, зв'язків і діючий бізнес-правил. Опис
інформаційно-довідкових задач приводиться окремо.
У результаті аналізу ПО були визначені наступні
сутності, їх атрибути та зв’язки:
Сутність Страва
Короткий опис сутності. Страва в меню. Містить
інформацію про всі страви в асортименті.
Атрибути. Сутність
характеризується наступними атрибутами:
· номер;
· назва;
· опис;
· рекомендований напій;
· вартість;
· група;
· вага.
Зв’язки. Сутність СТРАВА має наступні зв’язки з
іншими сутностями:
· СТРАВА обов’язково відповідає одній
і тільки одній ГРУПІ;
· СТРАВА може
відповідати одному і тільки одному НАПОЮ;
Бізнес-правила. Відносно сутності
страви діють наступні бізнес-правила:
· номер страви унікально ідентифікує її, так
як не можуть бути дві і більше страви з однаковим номером;
· назва має бути
унікальною;
· атрибути вартість та вага
не можуть бути від’ємними;
· атрибут рекомендований
напій є факультативним;
· усі інші атрибути страви є
обов’язковими.
Сутність Напій
Короткий опис сутності. Ця сутність містить
інформацію про всі напої, що є в асортименті.
Атрибути. Сутність
характеризується наступними атрибутами:
· номер;
· назва;
· об’єм;
· група;
· вартість;
· спосіб подачі.
Зв’язки. Сутність НАПІЙ має наступні зв’язки з
іншими сутностями:
· НАПІЙ обов’язково відповідає одній
і тільки одній ГРУПІ;
Бізнес-правила. Відносно сутності напою
діють наступні бізнес-правила:
· номер напою унікально ідентифікує його,
так як не можуть бути два і більше напої з однаковим номером;
· назва має бути
унікальною;
· атрибути вартість та
об’єм не можуть бути від’ємними;
· усі інші атрибути напою є
обов’язковими.
Сутність Інгредієнт
Короткий опис сутності. Описує інгредієнт, що
використовується для приготування.
Атрибути. Сутність
характеризується наступними атрибутами:
· номер;
· назва;
· одиниці виміру.
Зв’язки. Сутність ІНГРЕДІЄНТ має наступні зв’язки
з іншими сутностями:
· ІНГРЕДІЄНТ може використовуватись в
одному чи більше СКЛАДІ.
Бізнес-правила. Відносно сутності
інгредієнта діють наступні бізнес-правила:
· інгредієнт ідентифікується атрибутом
номер, тому він є обов’язковим та унікальним;
· назва має бути
унікальною;
· решта атрибутів є
обов’язковими.
Сутність Група
Короткий опис сутності. Сутність-класифікатор.
Призначення - перелік можливих груп страв або напоїв для зручнішої організації
даних. Може приймати значення гарячі страви, холодні страви, закуски, десерти,
алкогольні напої, безалкогольні напої, соки, чай, кава тощо.
Атрибути. Кваліфікується такими
атрибутами:
· номер;
· назва групи.
Зв’язки. Сутність ГРУПА має наступні зв’язки з
іншими сутностями:
· ГРУПА може ідентифікувати одну
чи більше СТРАВУ або НАПІЙ.
Бізнес-правила. Номер групи унікально
ідентифікує сутності цього типу, так як не може існувати два рівня з однаковим
номером. Назва групи є обов’язковим та унікальним атрибутом.
Сутність Склад
Короткий опис сутності. Містить набір
інгредієнтів, що входять в склад страви(напою).
Атрибути. Сутності СКЛАД
характеризується такими атрибутами:
· посилається на;
· номер напою;
· номер страви;
· номер інгредієнта;
· кількість.
Зв’язки. Сутність СКЛАД має наступні зв’язки з
іншими сутностями:
· СКЛАД обов’язково відповідає одній
СТРАВІ або одному НАПОЮ;
· СКЛАД обов’язково
містить один чи більше ІНГРЕДІЄНТ.
Бізнес-правила. Сутність представляє
собою перехідну для вирішення зв’язку «багато до багатьох»
· атрибут посилається на
приймає 2 значення (Страва або Напій);
· решта атрибутів є
обов’язковими;
· кількість не може бути
від’ємною.
Сутність Акція
Короткий опис сутності. Описує акцію, що
проходить в установі громадського харчування.
Атрибути. Сутності АКЦІЯ
характеризується наступними атрибутами:
· номер;
· назва;
· умови проведення.
Зв’язки. Сутність АКЦІЯ має наступні зв’язки з
іншими сутностями:
· АКЦІЯ може розповсюджуватись на одну
чи більше ПОЗИЦІЮ В МЕНЮ;
· Бізнес-правила. Номер акції є
унікальним та обов’язковим. Назва та умови проведення є обов’язковими
атрибутами. Назва має бути унікальною.
Сутність Позиція в меню
Короткий опис сутності. Містить всі позиції
сформованого меню.
Атрибути. Сутності ПОЗИЦІЯ В МЕНЮ
характеризується наступними атрибутами:
· посилається на;
· номер позиції;
· номер напою;
· номер страви;
· акція.
Зв’язки. Сутність ПОЗИЦІЯ В МЕНЮ має наступні
зв’язки з іншими сутностями:
· ПОЗИЦІЯ В МЕНЮ може мати в своєму
складі один чи більше НАПІЙ або одну чи більше СТРАВУ.
· ПОЗИЦІЯ В МЕНЮ може
приймати участь в одній чи більше АКЦІЇ.
Бізнес-правила. Атрибути акція, номер напою, номер страви є
факультативними. Решта атрибутів є обов’язковими. Атрибут посилається на
приймає 2 значення (Страва або Напій).
2.4 Інформаційно-довідкові задачі
Проведений аналіз предметної області дозволив
виділити перелік сутностей, що беруть участь у формуванні меню установи
громадського харчування. Аналіз цих сутностей та їх атрибутів, дозволяє
виділити декілька класів типових інформаційно-довідкових задач.
По-перше, інформація, що пов’язана з самими
стравами / напоями:
· надання повної та несуперечливої
інформації по групам страв/напоїв;
· надання інформації по
вартості, інгредієнтам.
По-друге, це інформація організаційного
характеру:
· надання інформації по акціям, що проходять
та позиціям меню, на які вони розповсюджуються.
По-третє, це інформація, що відноситься до
процесу формування меню:
· кількість страв/напоїв в меню;
· кількість представників
певної групи в меню.
3. Концептуальне моделювання предметної області
.1 Теоретичні положення концептуального моделювання
Етап концептуального моделювання - це побудова
строго опису ПО в термінах деякої формальної мови. На підставі змістовного
опису ПО, побудованого в результаті виконання етапу аналізу, будується строгий
формальний опис інформаційного забезпечення ПО, що автоматизується.
Концептуальне моделювання призначене для
інтегрованого опису інформаційного забезпечення ПО, що автоматизується, не
залежно від її сприйняття окремими користувачами й від способів її реалізації в
комп'ютерній системі.
Властивостями концептуальної моделі є наступні.
· Це основа однозначного розуміння ПО всіма
зацікавленими особами. У розробку складної системи баз даних включається
великий колектив: експерти, системні аналітики, проектувальники, розроблювачі,
ті, хто займається впровадженням і супроводом. Всі вони повинні однозначно
розуміти, що ж собою представляє ПО, що автоматизується, у який зміст
використовуваних понять, як вони взаємозалежні між собою, які всілякі обмеження
в ПО мають місце, які вимоги висуваються до різних функціональних компонентів
ПО й т.д. Все це повинна забезпечувати концептуальна модель. Це та єдина
платформа, що дозволяє всім розмовляти на одній й тіж мові й однаково розуміти
один одного.
· Вона включає тільки
концептуально релевантні аспекти ПО, крім, таким чином, БУДЬ-ЯКИХ аспектів
зовнішнього або внутрішнього представлення даних. Це означає, по перше, що
концептуальна модель жодним чином не повинна фіксувати конкретні потреби
окремих груп користувачів або додатків. Вона повинна фіксувати, що собою
представляє ПО в цілому, а не з погляду інтересів або потреб користувачів. Вона
повинна інтегрувати думки, погляди й інтереси окремих користувачів, але саме
інтегрувати, для одержання цілісної картини, а не виражати їхні конкретні
погляди, побажання думки. По-друге, у концептуальній моделі ПО ні яким чином не
повинні відбиватися які-небудь аспекти майбутньої реалізації БД у комп'ютерному
середовищі. Усе, що пов'язане з такими поняттями, як способи зберігання, методи
доступу, ефективність виконання, оптимізація й т.д. перебувають за межами
концептуальної моделі.
· Це засіб визначення
припустимої еволюції БД. У процесі експлуатації БД може розвиватися, однак цей
розвиток може вироблятися тільки в тих межах, які припустимі з погляду
концептуальної моделі. Розвиток бази даних, що вимагає змін у концептуальній
схемі, означає ні що інше, як переосмислювання ПО й завдань автоматизації й
побудови на цій основі нової концептуальної моделі ПО.
· Забезпечення незалежності
даних. Наявність концептуальної моделі, яка не залежить від зовнішнього
представлення користувачами ПО, та різними аспектами реалізації БД є надійна
основа вирішення задач досягнення логічної та фізичної незалежності програм від
даних.
· Централізоване
адміністрування. Саме через концептуальну схему здійснюється адміністрування
базами даних.
· Стійкість. Концептуальна
схема жодним чином не повинна змінюватися на догоду вимог тих або інших
користувачів або вимог зберігання даних. Будучи моделлю ПО, вона повинна
змінюватися тільки в тому випадку, коли входить у суперечність із нею.
Ключовими результатами етапу концептуального
моделювання э наступні:
· формальний опис інформаційного
забезпечення предметної області.
· докладний і строгий опис
сховищ даних.
· детальний опис потоків
даних.
· детальний опис ієрархії
розв'язуваних завдань із детальною специфікацією всіх завдань.
· детальний опис діючих у
предметній області правил і обмежень.
Існує безліч мов, які претендують на роль мов
концептуального моделювання ПО. У цей час найбільш популярними й повсюдно
використовуваними є мови, що ставляться до класу, так званих, графічних мов, що
оперують з такими поняттями, як сутність-атрибут-зв'язок. У наступному розділі
ми коротко опишемо одну з таких мов яка отримала назву мови ER-моделювання
предметних областей. Саме ця мова буде використана для представлення концептуальної
моделі ПО проходження практики студентами.
.2 Мова ER-моделювання ПО
Мова ER-моделювання (Entity Relationship Modeling) - це мова
визначення інформаційних потреб організації. Мова базується на концепції,
відповідно до якої інформаційне забезпечення будь-якої предметної області
представляється як сукупність взаємозалежних об'єктів. Процес моделювання
полягає у виділенні сутностей ПО, установлення властивостей
виділених сутностей і виявлення існуючих між ними зв'язків.
Моделювання сутностей і зв'язків може
використовуватися не тільки на етапі концептуального моделювання, але і на
етапах розробки стратегії і аналізу, й і ставить основною метою створення
точної й адекватної моделі інформаційних потреб організації.
Розглянемо коротко основні властивості, формальні
позначення й визначення сутностей, зв'язків, атрибутів.
Сутність - це реальний або
уявлюваний об'єкт інтересу, інформація про який підлягає збору або зберіганню.
Графічно сутність представляється пойменованим прямокутником із закругленими
кутами. Ім'я сутності дається в однині й пишеться заголовними буквами. Ім'я
сутності повинне бути таким, щоб представляти тип або клас об'єктів, а не
окремий екземпляр. Будь-який предмет або об'єкт може бути представлений тільки
однією сутністю. Інакше кажучи, сутності завжди є взаємовиключними.
Зв'язок - це деяка пойменована асоціація, що
представляє інтерес, двох сутностей. Зв'язок є бінарним в тому розумінні, що це
завжди асоціація в точності двох сутностей або сутності із самої собою. Кожний
зв'язок має два кінці, для кожного з яких є свої:
· ім'я;
· ступінь/потужність;
· факультативність -
обов'язкова або факультативна.
Ці властивості використовуються для опису
асоціації з кожної зі сторін, для завдання зв'язку повинні бути визначені
обидва її кінця.
На діаграмах зв'язки представляються лініями, що
з'єднують два прямокутники сутностей. Одним з видів зв'язку представлений на
наступному рис. Це зв'язок зі ступенем багато-до-одному, обов'язковий в
закінченні зі ступенем «багато», і факультативний на протилежному кінці.
Приклад зв'язку
У закінчення зі ступенем «багато» закінчення зв'язку
з'єднується із прямокутником у трьох точках. У закінчення зі ступенем «один»
з'єднання здійснюється тільки в одній точці. Та половина зв'язку, що перебуває
з боку обов'язкового її кінця, рисується суцільною лінією, а та, що з
факультативної сторони, - переривчастої.
При читанні зв'язку з обов'язкової сторони перед її ім'ям
використовуються слова «у всіх випадках» або «завжди»; для факультативної
сторони використовуються слова «у загальному випадку» або «іноді». Ступінь
«багато» читається як «один або декілька», а ступінь «один» - «один і тільки
один».
Атрибут - це будь-яка деталь або аспект, що
сприяють якісному або кількісному опису сутності, її ідентифікації,
класифікації або відбиттю її стану. Атрибутом може бути текст, число, картинка,
почуття, запах. Загалом, усе, що потрібно. Займаючись обробкою даних, ми
намагаємося в основному обмежитися текстами й числами.
Для подання атрибута пишеться його ім'я малими літерами в
однині, можливо, із прикладами значень. Атрибути необов'язково показувати на
діаграмі сутностей і зв'язків, однак додавання до сутності одного-двох
атрибутів у період формування моделі, як правило, виявляється досить корисним.
Атрибут описує одну сутність. Атрибут повинен описувати ту
сутність, до якої він віднесений. У кожний момент часу сутність може володіти
лише одним значенням атрибута.
Атрибут, значення якого може бути відсутнім, називається факультативним.
Він позначається символом «°» перед його ім'ям. Атрибут, значення якого повинне бути завжди
відомо, називається обов'язковим, і позначається зірочкою «*» перед
ім'ям. Обов'язковість означає, що сутність може бути визначена тоді й тільки
тоді, коли відомі значення всіх її обов'язкових атрибутів. Всі атрибути
унікального ідентифікатора повинні бути обов'язковими.
Кожна сутність повинна однозначно ідентифікуватися за
допомогою деякої комбінації атрибутів і/або зв'язків. Тому серед можливих
атрибутів сутності завжди повинні бути знайдені такі атрибути, які дозволяють
неї ідентифікувати. Унікальний ідентифікатор представляється на
ER-Діаграмі вказівкою символу «#» перед ім'ям кожного атрибута, що входить у
даний ідентифікатор. Значення усіх інших атрибутів повинні залежати від усього
унікального ідентифікатора.
Дуже важливо чітко розуміти, що всі визначення сутності,
зв'язку, атрибута й унікального ідентифікатора, які ми тільки що розглянули,
суть визначення типу, або класу, поняття, а не екземпляра. Екземпляри сутностей
і зв'язків будуть представлені в самій базі даних.
.2 Побудова концептуальної моделі проходження практики студентами
На основі проведеного аналізу предметної області
була побудована концептуальна модель з використанням мови ER-моделювання.
Концептуальна модель наведена на наступному рисунку. Дамо декілька зауважень:
· По-перше, ця модель не містить опису
атрибутів сутностей у зв’язку з відсутністю місця для їх зображення.
Передбачається, що атрибути сутностей разом з їх властивостями
(бізнес-правилами) детально описані на етапі аналізу.
· По-друге, мова
ER-моделювання не передбачає детального представлення інформаційно-довідкових
задач. Ми припускаємо, що вони мають звичайний текстовий опис, який
представлений на етапі аналізу.
4. Логічне та фізичне проектування бази даних
Завдання цього етапу полягає у проведенні
логічного та фізичного проектування бази даних.
Логічне проектування - це розробка логічної
структури системи баз даних без прив'язки до конкретної СУБД, структур збереження,
методам доступу і т.д.
Фізичне проектування - це проект системи бази
даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і
зв'язків перетворюється в схему бази даних і специфікації позамашинного
збереження.
.1 Логічне проектування
У якості логічній моделі бази даних була обрана
реляційна модель, оскільки саме реляційна модель використовується у більшості
розвинених СКБД.
Для перетворення концептуальної моделі,
представленої у вигляді мови ER-моделювання, у реляційну модель, був
використаний наступний алгоритм.
· Крок 1. Перетворення
сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності
представляється у вигляді семантично осмисленого імені у латинському алфавіті.
· Крок 2. Перетворення
атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту
представляється у вигляді семантично осмисленого імені у латинському алфавіті.
У цей момент уточнюється формат представлення значень стовпця. Факультативні
атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
· Крок 3. Подання
унікальних ідентифікаторів ключами таблиць. Складові унікального
ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність
може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий
використовується найбільше часто. Всі інші унікальні ідентифікатори приймають
обмеження цілісності UNIQUE NOT та NOT NULL.
Концептуальна ER-модель меню установи
громадського харчування
Сутність може унікально ідентифікуватися
комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі
сутності зв'язку до складу первинного ключа включається зовнішній ключ, який
посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.
· Крок 4. Перетворення
зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу
багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи,
необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в
закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з
боку зв'язку «багато» як стовпці. Факультативним зв'язкам відповідають
NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
· Крок 5. Введення
спеціальних первинних ключів. Для більш адекватного відображення логічного
проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець
з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість
первинного ключа згідно з концептуальною моделлю, набувають обмеження
цілісності UNIQUE та NOT NULL.
Повна логічна база даних на основі концептуальної
моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально
представлена в наступних таблицях.
Таблиця 1. Відношення сутності СТРАВА
DISH
|
Ім’я
стовпця
|
Тип
|
Довжина
|
Призначення
|
Обмеження
цілісності стовпців
|
|
DISH_ID
|
ціле
число
|
10
|
Унікальний
ID
|
Первинний
ключ
|
|
Name
|
рядок
|
30
|
Назва
|
Обов’язковий,
унікальний
|
|
Description
|
рядок
|
255
|
Опис
страви
|
Обов’язковий
|
|
Rec_Drink
|
ціле
число
|
10
|
Зв’язок
з напоєм
|
Зовнішній
ключ, що посилається на первинний ключ відношення DRINK. Факультативний.
|
|
Cost
|
число
|
3,2
|
Вартість
|
Обов’язковий,
невід’ємний
|
|
GrpFK
|
ціле
число
|
10
|
Зв’язок
з групою
|
Зовнішній
ключ, що посилається на первинний ключ відношення GROUP. Обов’язковий
|
|
Weight
|
число
|
3,2
|
Вага
|
Обов’язковий,
невід’ємний
|
Таблиця 2. Відношення сутності НАПІЙ
DRINK
|
Ім’я
стовпця
|
Тип
|
Довжина
|
Призначення
|
Обмеження
цілісності стовпців
|
|
DRNK_ID
|
ціле
число
|
10
|
Унікальний
ID
|
Первинний
ключ
|
|
Name
|
рядок
|
Назва
|
Обов’язковий,
унікальний
|
|
Volume
|
дійсне
число
|
1,2
|
Об’єм
|
Обов’язковий,
невід’ємний
|
|
GrpFK
|
ціле
число
|
10
|
Зв’язок
з групами
|
Зовнішній
ключ, що посилається на первинний ключ відношення GROUP. Обов’язковий
|
|
Cost
|
число
|
3,2
|
Вартість
|
Обов’язковий,
невід’ємний
|
|
Presentation
|
рядок
|
255
|
Спосіб
подачі
|
Факультативний
|
Таблиця 3. Відношення сутності ІНГРЕДІЄНТ
|
Ім’я
стовпця
|
Тип
|
Довжина
|
Призначення
|
Обмеження
цілісності стовпців
|
|
INGR_ID
|
ціле
число
|
10
|
Унікальний
ID
|
Первинний
ключ
|
|
Name
|
рядок
|
15
|
Назва
інгредієнта
|
Обов’язковий,
унікальний
|
|
Units
|
рядок
|
20
|
Одиниці
виміру
|
Обов’язковий
|
Таблиця 4. Відношення сутності ГРУПА
GRUP
|
Ім’я
стовпця
|
Тип
|
Довжина
|
Призначення
|
Обмеження
цілісності стовпців
|
|
GRP_ID
|
ціле
число
|
10
|
Унікальний
ID
|
Первинний
ключ
|
|
Name
|
рядок
|
30
|
Назва
групи страв/напоїв
|
Обов’язковий,
унікальний
|
Таблиця 5. Відношення сутності СКЛАД
PROD_SET
|
Ім’я
стовпця
|
Тип
|
Довжина
|
Призначення
|
Обмеження
цілісності стовпців
|
|
Referes_to
|
строка
|
10
|
Обов’язковий.
|
|
DshFK
|
ціле
число
|
10
|
Зв’язок
з DRINK
|
Зовнішній
ключ, що посилається на первинний ключ відношення DRINK. Факультативний
|
|
DrnkFK
|
ціле
число
|
10
|
Зв’язок
з DISH
|
Зовнішній
ключ, що посилається на первинний ключ відношення DISH. Факультативний
|
|
IngrFK
|
ціле
число
|
10
|
Зв’язок
з INGREDIENT
|
Зовнішній
ключ, що посилається на первинний ключ відношення Ingredient. Обов’язковий
|
|
Quantity
|
ціле
число
|
10
|
Кількість
|
Обов’язковий,
невід’ємний
|
Таблиця 6. Відношення сутності АКЦІЯ
SPECIAL
|
Ім’я
стовпця
|
Тип
|
Довжина
|
Призначення
|
Обмеження
цілісності стовпців
|
|
SPC_ID
|
ціле
число
|
10
|
Унікальний
ID
|
Первинний
ключ
|
|
Name
|
рядок
|
30
|
Назва
акції
|
Обов’язковий,
унікальний
|
|
Description
|
рядок
|
255
|
Умови
акції
|
Обов’язковий.
|
Таблиця 7. Відношення сутності ПОЗИЦІЯ В МЕНЮ
MENU_POS
|
Ім’я
стовпця
|
Тип
|
Довжина
|
Призначення
|
Обмеження
цілісності стовпців
|
|
MP_ID
|
ціле
число
|
10
|
Унікальний
ID
|
Первинний
ключ
|
|
Refers_to
|
рядок
|
10
|
Вказує,
на що буде посилання (трава/напій)
|
Обов’язковий
|
|
DshFK
|
ціле
число
|
10
|
Зв’язок
з DISH
|
Зовнішній
ключ, що посилається на первинний ключ відношення DISH. Факультативний
|
|
DrnkFK
|
ціле
число
|
10
|
Зв’язок
з DRINK
|
Зовнішній
ключ, що посилається на первинний ключ відношення DRINK. Факультативний
|
ціле
число
|
10
|
Зв’язок
з SPECIAL
|
Зовнішній
ключ, що посилається на первинний ключ відношення SPECIAL. Факультативний
|
4.2 Фізичне проектування
База даних спроектована для її збереження у СКБД
Oracle, яка підтримує реляційну модель даних і є об’єкто-реляційною СКБД. Ця
СКБД має дуже розвинені можливості по створенню та супроводу баз даних,
оскільки володіє найбільш розвиненою системою типів даних, можливостями
індексування полів, що дозволяє одержувати доступ до даних за мінімальний час,
а також функціями по забезпеченню підтримки цілісності даних між реляційними
таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення
бази даних, а кінцевому користувачеві витрати на підтримку цілісності
збережених даних і одержання даних з бази даних. Робота з базою даних
підтримується за допомогою реляційної мови запитів SQL.
Логічна модель бази даних легко відображається в
реляційну фізичну модель, оскільки логічна модель була побудована з
використанням реляційної структури даних. Крім того, логічна модель була
приведена у третю нормальну форму, тому усі відношення представляються у
фізичній моделі окремими таблицями. Ніякі злиття відношень в одну таблицю для
підвищення ефективності виконання окремих класів запитів не виконуються у
зв’язку з тим, що такі класи запитів не були знайдені. У результаті отримано
сімнадцять таблиць реляційної бази даних, де кожне відношення прямо відповідає
окремій таблиці, атрибути кожного відношення стають полями цієї таблиці, а
первинні ключі відношень стають первинними ключами таблиць.
Скрипти створення бази даних
Наведемо скрипт мови SQL Oracle, який створює
таблиці БД.
Створення таблиці GRUPTABLE GRUP (_ID INTEGER
PRIMARY KEY,VARCHAR(30) UNIQUE NOT NULL,);
Створення таблиці INGREDIENTTABLE INGREDIENT (_ID
INTEGER PRIMARY KEY,VARCHAR(30) UNIQUE NOT NULL,VARCHAR(15) NOT NULL,);
Створення таблиці DRINKTABLE DRINK (_ID INTEGER
PRIMARY KEY,VARCHAR(30) UNIQUE NOT NULL,NUMERIC (1,1) NOT NULL CHECK
(VOLUME>0),VARCHAR(255) NOT NULL,DECIMAL (3,2) NOT NULL CHECK
(COST>=0),INTEGER FOREIGN KEY REFERENCES GRUP (GRP_ID),);
Створення таблиці DISHTABLE DISH (_ID INTEGER
PRIMARY KEY,VARCHAR(30) UNIQUE NOT NULL,VARCHAR(255) NOT NULL,_DRINK INTEGER
FOREIGN KEY REFERENCES DRINK (DRNK_ID),NUMERIC (3,2) NOT NULL CHECK
(WGHT>=0),DECIMAL (3,2) NOT NULL CHECK (COST>=0),INTEGER FOREIGN KEY
REFERENCES GRUP (GRP_ID),);
Створення таблиці PROD_SETTABLE PROD_SET (_ID
INTEGER PRIMARY KEY,_TO VARCHAR(10) CHECK (REFERS_TO IN ('Страва',
'Напій')),INTEGER FOREIGN KEY REFERENCES DISH (DISH_ID),INTEGER FOREIGN KEY
REFERENCES DRINK (DRNK_ID),INTEGER FOREIGN KEY REFERENCES INGREDIENT
(INGR_ID),NUMERIC (2,2) NOT NULL CHECK (QUANTITY>0),);
Створення таблиці SPECIALTABLE SPECIAL (_ID
INTEGER PRIMARY KEY,VARCHAR(30) UNIQUE NOT NULL,VARCHAR(255) NOT NULL,);
Створення таблиці MENU_POSTABLE MENU_POS (_ID
INTEGER PRIMARY KEY,_TO VARCHAR(10) CHECK (REFERS_TO IN ('Страва', 'Напій'))
NOT NULL,INTEGER FOREIGN KEY REFERENCES DISH (DISH_ID),INTEGER FOREIGN KEY
REFERENCES DRINK (DRNK_ID),INTEGER FOREIGN KEY REFERENCES SPECIAL (SPC_ID),);
Інформаційно-пошукові запити
Наведемо приклади інформаційно пошукових запитів
відносно тих задач, які були окреслені в підрозділі «2.4.
Інформаційно-довідкові задачі». Приклади наведемо у мові SQL Oracle з використанням
бази даних, визначеної у попередньому підрозділі.
Інформація, що пов’язана з самими стравами / напоями:
Запит 1. Вивести перелік назв та
цін страв та напоїв, що коштують від 20 до 100 гривень
SELECT DISH. Name, DISH. Cost, DRINK.NAME,
DRINK. Cost
FROM DISH, DRINK
WHERE (DISH.COST>20 AND DISH.COST<100) OR
(DRINK.COST>20 AND DRINK.COST<100)
Запит 2. Вивести назви страв, що
входять в групу гарячі страви.
SELECT DISH. Name
FROM DISH, GRUP
WHERE DISH. GrpFK = GRUP.GRP_ID AND GRUP.NAME =
‘Гарячі
страви’
Інформація організаційного характеру
Запит 1. Скільки позицій меню
беруть учать в акції «Щасливі години».
SELECT COUNT(*)
FROM MENU_POS, SPECIAL
WHERE MENU_POS. SpcFK = SPECIAL.SPC_ID AND
SPECIAL.NAME = ‘Щасливі години’
Запит 2. Вивести назви та умови
проведення всіх акцій, що проводяться
SELECT SPECIAL.NAME, SPECIAL.DESCRIPT
FROM SPECIAL
Інформація, що відноситься до процесу формування меню:
Запит 1. Визначити кількість
напоїв в меню
SELECT COUNT(*)
FROM MENU_POS
WHERE MENU_POS. DrnkFK IS NOT NULL
Запит 2. Визначити кількість
алкогольних напоїв в позиціях меню
SELECT COUNT(*)
FROM MENU_POS, DRINK, GRUP MENU_POS.
DrnkFK = DRINK.DRNK_ID AND DRINK. GrpFK = GRUP.DGRP_ID AND GRUP.NAME = ‘Алкогольні напої’
Висновки
Проектування баз даних - це складний,
багатокроковий процес перетворення інформаційного середовища ПО у інформаційну
модель у вигляді бази даних. Цей процес складається з різних етапів, а саме:
розробка стратегії автоматизації, аналіз ПО, побудова концептуальної моделі ПО,
логічне та фізичне проектування БД. На сучасному етапі розвитку інформатики
проектування баз даних перетворилося на цілком сформовану наукову дісціпліну,
яка має у своєму складі формально-теоретичну та технологічну складові.
Теоретичної основою проектування баз даних є теорія нормалізації, яка дозволяє
чітко і строго відповісти на таке запитання: як слід проводити перетворення початкової
схеми ПО таким чином, щоб результуюча схема бази даних була еквівалентна
початковій і була краща за неї. Методологія проектування детально описує усі
етапи життєвого циклу створення бази даних з використанням сучасних мов опису
ПО.
Ціллю курсового проекту було проектування бази
даних меню установи громадського харчування.
Для виконання курсового проекту були проведені
всі необхідні дослідження, що стосуються розробки стратегії автоматизації, в
результаті яких була надана відповідь на принципові запитання, що стосуються
автоматизації будь-якої предметної області.
Після цього був проведений аналіз ПО в результаті
якого був отриманий змістовний опис ПО. Для аналізу ПО використовувалися наявні
документи, а саме: приклади затверджених меню, що використовуються в діючих
мережах установ громадського харчування.
Після цього була побудована концептуальна модель.
Для цього була використана мова ER-опису ПО, яка базується на концепції, що
інформаційна модель будь-якої ПО може бути описана із застосування таких понять,
як сутність, атрибут, зв’язок. Крім того, ця мова є суттєво графічною, що дає можливість
наочно представляти концептуальну модель ПО. При побудові концептуальної моделі
неявно використовувалися результати теорії нормалізації, у зв’язку з цим побудована
модель представлена у третій нормальній формі. Необхідності використання більш
високих нормальних форм не було, так як у предметній області не були виявлені
складні види транзитивних функціональних залежностей, а також багатозначні
залежності.
Логічне та фізичне проектування БД складалося з
конвертації концептуальної моделі ПО у реляційну модель даних. При цьому був
використаний алгоритм конвертування схеми ПО у мові ER в схему реляційної бази
даних.
Після
цього реляційна база даних була представлена у вигляді команд створення таблиць
бази даних у мові SQL ORACLE. Крім того, у мові SQL описані деякі
інформаційно-пошукові запити.
Виконаний курсовий проект надав мені можливість
ознайомитися з технологією проектування баз даних, та отримати практичний досвід
у проектуванні бази даних з конкретної предметної області.