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

ВСТУП

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

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

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

Курсова робота викладена на 44 сторінок комп'ютерного тексту і складається зі вступу, висновків та додатків, чотирьох розділів, висновків та 9 додатків. Бібліографічний список включає 13 літературних джерел на одній сторінці. Робота містить 3таблиці і 9 рисунків загальним обсягом 12 сторінок.

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

Дослідивши та розкривши питання першого розділу відбувається перехід до другого розділу, у якому аналізується документація пункту ресторану. У цьому розділі вказується перелік завдань, які буде виконувати база даних. Це дозволяє визначити основні сутності та атрибути бази даних ”Ресторан”.

У третьому розділі відображається логічне проектування та проводиться нормалізація бази даних для побудови ER-діаграми. Вона дає можливість перейти до автоматизації довідкової інформації ресторану з попереднім вибором та обґрунтуванням СКБД.

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



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

Предметна область, частина якої представлена ??в цій курсовій роботі - реалізація бази даних інформаційної системи ресторану. Ресторан є актуальною темою, тому ресторанний бізнес у наш час справа модна і дуже прибуткова. У сучасному світі існує величезна кількість підприємств харчування, і вижити в цій конкурентній боротьбі дуже складно. І щоб “утриматися на плаву”, а бажано бути популярним, отримувати гарний прибуток і подобатися людям, потрібно вносити нову ідею у вже існуючий, звичний усім ресторан або кафе. Або при відкритті нового підприємства зробити щось таке чого ще не було в місті. Практично вся документація будь-якої фірми є автоматизованою. Тому нові технології нам дозволяють створити базу даних, яка задовольняє підприємця. Використовуючи базу даних, користувач може швидко отримати необхідну йому інформацію.

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

З мети роботи випливають і її завдання:

ь Створити структуру таблиць бази даних

ь Виконати заповнення таблиць інформацією.

ь Зв'язати таблиці за допомогою зовнішніх ключів

ь Створити необхідні запити для аналізу діяльності ресторану

ь Створити форми введення та виведення інформації

ь Створити необхідні звіти, що відображатимуть аналіз організації роботи ресторану

ь Створити головну кнопочку форму

ь Забезпечити безпеку бази даних.

Предмет та об'єкт дослідження

Об'єкт дослідження - ресторанний бізнес.

Предмет дослідження - концепція ресторану, як невід'ємна частина ресторану та ресторанної діяльності.

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

Вимоги до бази даних.

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

Вимоги до програмного і технічного забезпечення.

Для повноцінного функціонування бази даних необхідно: комп'ютер з процесором AMD AlthonXP, Intel Pentium 2,4 ГГц RAM 768 Мб з оперативної системою Windows 2000/Me/XP з встановленою Microsoft Access.

1.1 Основні сторони-учасники у предметній області інфраструктури

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

Головною задачею ресторанів являється надання платних послуг населенню (клієнтам) у формі суспільно організованого харчування.

Для розрахунку витрат ресторана використовуються такі дані:

· фонд заробітної плати співробітників (190000 грн);

· закупівля обладнання (30000 грн);

· зовнішня реклама (121000 грн);

· комунальні послуги (25500 грн);

· ліцензування (7000 грн);

· маркетингове дослідження (5000 грн);

· оренда приміщення (100000 грн);

· продукти (255000 грн);

· ремонт приміщень (29000 грн);

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



РОЗДІЛ 2.КОНЦЕПТУАЛЬНА МОДЕЛЬ “СУТНІСТЬ-ЗВ'ЯЗОК”

2.1 Дослідження документів, які застосовуються у роботі на підприємстві

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

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

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

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

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

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

Фізична модель визначає розміщення даних, методи доступу та техніку індексування. Рішення проблем проектування на фізичному рівні багато в чому залежить від системи управління базами даних, що використовується. Воно автоматизоване і сховане від користувача.

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

o ієрархічна;

o мережна;

o реляційна;

o об'єктно - орієнтована.

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

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

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

Елемент реляційної моделі	Форма представлення
Атрибут	Заголовок стовпця
Відношення	Таблиця
Домен	Стовпець таблиця
Кортеж	Рядок таблиці
Первинний ключ	Один або кілька атрибутів
Сутність	Опис властивостей об'єкту
Схема відношення	Рядок заголовків таблиці
Тип даних	Тип значень елементів таблиці

Сутність - це об'єкт будь-якої природи. Дані про об'єкт зберігаються в базі даних. Дані про сутність зберігаються у відношенні.

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

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

Домен - це множина атомарних значень одного типу.

Кортеж - це значення всіх атрибутів одного екземпляру сутності у відношенні.

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

2.2 Визначення сутностей, атрибутів, зв'язків у предметній області

Об'єкти бази даних

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

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

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

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

Страва -- поєднання продуктів харчування, які доведені до кулінарної готовності, порціоновані, оформлені і готові до споживання.[1]

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

Напої ---- рідини, що вживаються для пиття. Поділяються на спиртні та безалкогольні напої.

2.3 Концептуальна модель

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

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

Рис. 2.2. Концептуальна модель майбутньої бази даних для роботи



2.4 Створення базової ER-моделі предметної області

У цьому розділі спроектовано модель типу “сутність-зв'язок”, яка відповідає окремим автоматизованим функціям.

На основі завдань, які буде виконувати база даних виділено об'єкти, які будуть сутностями моделі. Атрибути сутностей, тобто властивості об'єктів, будуть відображатись для кращого розуміння з'язку між сутностями.

Виділивши у предметній області сутності та їх атрибути можна побудувати модель типу “сутність-зв'язок”.

На діаграмі ER-моделей, які зображені нижче, прямокутники означають сутності з атрибутами. Між сутностями встановлюються зв'язки типу “один до багатьох” і “один до одного”.



РОЗДІЛ 3. ЛОГІЧНА СТРУКТУРА БАЗИ ДАНИХ. НОРМАЛІЗАЦІЯ БАЗИ ДАНИХ

3.1 Побудова логічної структури бази даних на основі ER-моделі

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

Спрощення концептуальної моделі

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

На цьому етапі виконуються такі операції:

Ш вилучення складних зв'язків;

Ш вилучення багатозначних атрибутів;

Ш вилучення рекурсивних зв'язків;

Ш вилучення зв'язків з атрибутами.

Після спрощення в концептуальнім моделі можуть бути присутні лише такі елементи:

· об'єкти і атрибути;

· зв'язки типу один до одного і до багатьох;

· зв'язки типу суперклас-підклас.

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

Концептуальну модель перетворено у логічну модуль даних за певними правилами :

· визначено кількість відношень(за умовою їх має бути не менше семи);

· перевірено зв'язки між сутностями( усунено зв'язки, які є несумісними з реляційною моделлю);

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

Рис. 3.1 Схема функціонування інформації у БД “ Ресторан”

3.2 Побудова обмежень відношень бази даних

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

Отримана ER-модель має безліч аномалій та недоліків:

· існуючі відношення неповністю відображають суть теми курсової роботи;

· існують рекурсивні зв'язки, які можуть бути перетворені в одне відношення;

· кількість атрибутів;

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

3.3 Вибір та обґрунтування СКБД

Вибір системи управління баз даних (СКБД) являє собою складну багатопараметричної задачі і є одним з важливих етапів при розробці
додатків баз даних. Обраний програмний продукт повинен задовольняти як поточним, так і майбутнім потребам підприємства, при цьому слід враховуватифінансові витрати на придбання необхідного обладнання, самої системи, розробку необхідного програмного забезпечення на її основі, а також навчання персоналу. Крім того, необхідно переконатися, що нова СУБД здатна принести підприємству реальні вигод.

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

Основні характеристика бази даних:

· Контроль за надлишковістю даних

· Несуперечливість даних

· Підтримка цілісності бази даних (коректність та несуперечливість)

· Цілісність описується за допомогою обмежень

· Незалежність прикладних програм від даних

· Спільне використання даних

· Підвищений рівень безпеки

Можливості СКБД:

· Контроль за надлишковістю даних

· Несуперечливість даних

· Підтримка цілісності бази даних (коректність та несуперечливість)

· Цілісність описується за допомогою обмежень

· Незалежність прикладних програм від даних

· Спільне використання даних

· Підвищений рівень безпеки

На мою думку вдалою СКБД є Microsoft Access, яка виконує вище перераховані функції та ряд інших з можливістю використання екранних інструментів.



РОЗДІЛ 4. РЕАЛІЗАЦІЯ ДАНИХ ЧЕРЕЗ СКБД

4.1 Нормалізація бази даних

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

Надлишковість даних в БД є небажаним явищем, оскільки призводить до збільшення об'єму пам'яті, уповільнює роботу БД. Надлишковість даних є результатом в першу чергу дублювання даних. Розрізняють незбиткове та збиткове дублювання даних. Повністю усувати надлишковість не потрібно, оскільки при цьому неможливо буде підтримувати БД як єдине ціле. Слід тільки мінімізувати надлишковість, залишивши необхідне дублювання даних.

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

4.2 Автоматичні коригування даних у базах інформаційної системи

Реалізація завдань, які виконує база даних “Ресторан”, виконується через Microsoft Access і починається вона зі створення таблиць (відношень) згідно логічної схеми. Ці таблиці зв'язані через вікно Схема даных.



Рис.4.1 Вікно “Схема даних” зі зв'язками відношень БД “Ресторан”

Далі заповнено раніше створені таблиці та створено різні види запитів, використовуючи Конструктор запросов, та Майстер запросoв.

Рис.4.2 Вікно “Запросы” із запитами БД “Ресторан”



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

Рис.4.3 Вікно із формами БД “Ресторан”

4.3 Засоби автоматизації управління системою

Після відкриття моєї бази даних “Ресторан” автоматично включається головна кнопочна форма. Вона має ось такий вигляд:



Рис.4.4 Головна кнопкова форма БД ”Ресторан”

Головна кнопкова форма містить екранні вкладки(Облік діяльності, Автоматичні обрахунки, Звіти, Задачі бази даних, Довідники.), які вирішують поставлені задачі. На першій та останній закладках розміщено кнопки виклику всіх розроблених основних форм. На закладці Автоматичні обрахунки розміщено кнопки для виклику всіх розроблених запитів з обчислювальними полями, що не викликалися з інших форм. Із закладки Звіти відповідні кнопки повинні викликають всі звіти, а із закладки Задачі бази даних - всі розроблені запити, які вирішують задачі БД. Під набором вкладок розміщується кнопка для завершення роботи.

Із другої вкладки “Автоматичні обрахунки” видно:

Із третьої вкладки “Звіти” видно:



Із четвертої вкладки “Задачі баз даних” видно:

Кнопка ”Бухгалтерія” головної кнопкової форми вкладки “Задачі бази даних” відкриває запит, що обраховує зарплату. Ці дані є доступні лише для адміністратора бази даних, тому коли користувач нажимає кнопку ”Бухгалтерія” на екрані з'являється діалогове вікно:

У разі введення невірного паролю, на екрані з'являється діалогове вікно, яке має такий вигляд:

Із п'ятої вкладки “Довідники” видно:

Кнопка “Презентація Меню” головної кнопкової форми вкладки “Довідники” має адресу гіперпосилання, що відкриває презентацію “Меню ресторана” бази даних “Ресторан” у програмі Microsoft PowerPoint.



ВИСНОВОК

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

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

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

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

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

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

1. Microsoft Access 2007. Разработка приложений на реальном примере Автор: Гурвиц Г.А.

2. Создание и использование баз данных Автор: Черноусова А.М.

3. Базы данных Автор: Ахмадеев И.А., Хайруллин А.Х.

4. Базы данных. Проектирование и создание Автор: Диго С.М.

5. Технологии баз данных и знаний Автор: Бородина А.И.

6. Виейра Р. Программирование баз данных Microsoft SQL Server 2005 для профессионалов. - Диалектика, 2008. - 1066 ст.

7. Дубейковский В.И. Эффективное моделирование с CA ERwin ProcessModeler (BPwin; AllfusionProcessModeler). 2-е изд., исп. и доп. - Диалог-МИФИ, 2009. - 384 ст.

8. Дьюсон Р. SQL Server 2008 для начинающих разработчиков. - BHV, 2009. - 704 ст.

9. Лобел Л. Разработка приложений на основе Microsoft SQL Server 2008. - Русская редакция, 2009. - 1024 с.

10. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. - Диалог-МИФИ. - 256 с.

11. Фленов М. Transact-SQL. - БХВ-Петербург, 2006. - 576 ст.

12. Завадський І.О. Основи баз даних (2011) - 104 ст.

13. Морзе Н.В. Бази даних у навчальному процесі(2007) - 47 ст.



ДОДАТКИ

Додаток А



Дадаток Б

SELECT Бухгалтерія.Код, Бухгалтерія.Призвіще, Бухгалтерія.[Ім'я працівника], Бухгалтерія.[По батькові], Працівники.Посада, Бухгалтерія.[Кількість робочих годин], Бухгалтерія.[Ціна (за год)], Бухгалтерія.[Кількість годин на добу], Бухгалтерія.Зарплата

FROM Працівники INNER JOIN Бухгалтерія ON Працівники.[Ім'я працівника] = Бухгалтерія.[Ім'я працівника];



Додаток В

SELECT Страви.Назва, Count(Страви.Назва) AS количество, Страви.Ціна

FROM Страви

WHERE (((Страви.Ціна)>50 And (Страви.Ціна)<150))

GROUP BY Страви.Назва, Страви.Ціна;

Додаток Г

SELECT Працівники.Прізвище, Працівники.[Ім'я працівника], Працівники.[По-Батькові], Працівники.Посада, Бухгалтерія.Зарплата

FROM Посада INNER JOIN (Працівники INNER JOIN Бухгалтерія ON Працівники.[Ім'я працівника] = Бухгалтерія.[Ім'я працівника]) ON (Посада.[Код посади] = Працівники.[Код посади]) AND (Посада.[Код посади] = Бухгалтерія.[Код посади])

WHERE (((Працівники.[Ім'я працівника])=[Введіть Ім'я працівника"]));



Додаток Д

TRANSFORM Min(Замовлення.[Загальна сума]) AS [Min-Загальна сума]

SELECT Замовлення.[Код замовлення], Замовлення.[Номер столика], Замовлення.[Ім'я працівника], Min(Замовлення.[Загальна сума]) AS [Итоговое значение Загальна сума]

FROM Замовлення

GROUP BY Замовлення.[Код замовлення], Замовлення.[Номер столика], Замовлення.[Ім'я працівника]

PIVOT Замовлення.[Дата замовлення];



Додаток Е

TRANSFORM Sum([підзапит інгредієнти].Собівартість) AS [Sum-Собівартість]

SELECT [підзапит інгредієнти].[Код страви], [підзапит інгредієнти].Назва, Sum([підзапит інгредієнти].Собівартість) AS [Итоговое значение Собівартість]

FROM [підзапит інгредієнти]

GROUP BY [підзапит інгредієнти].[Код страви], [підзапит інгредієнти].Назва

PIVOT [підзапит інгредієнти].[Одиниця виміру];



Додаток Є

TRANSFORM Sum([під запит столик].Ціна) AS [Sum-Ціна]

SELECT [під запит столик].[Номер столика], Sum([під запит столик].Ціна) AS [Итоговое значение Ціна]

FROM [під запит столик]

GROUP BY [під запит столик].[Номер столика]

PIVOT [під запит столик].[Ім'я працівника];



Додаток Ж

Додаток З



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

...