і щоденного меню і управлінням закупівлею продуктів. Предметом мого дослідження діяльності ресторану є процес обслуговування клієнтів. Для того щоб краще зрозуміти логіку цього процесу, мною було прийнято рішення декомпозировать роботу по обслуговування клієнтів на дві подработи: обслуговування столика і розрахунок відвідувача.
З діаграми випливає, що робота офіціанта полягає в обслуговування столика, тобто це прибирання столика після відвідувача, подача меню новому відвідувачеві і прийняття його замовлення, передача цього замовлення на кухню та адміністратору залу для формування рахунку, подача готового замовлення відвідувачеві і, в разі необхідності, прийняття нового замовлення, після задоволення відвідувачем своїх потреб подача йому рахунки за послуги і прийняття грошей.
Адміністратор залу формує рахунки на оплату відвідувачів, стежить за правильністю подачі замовлення офіціантом і в разі неспівпадання замовлення відвідувача і того що йому принесли залагоджує неприємності.
.2 Побудова моделі потоків даних
Для того щоб виділити потоки даних необхідно побудувати діаграму DFD. При побудові діаграми мною були виділені дві основні зовнішні сутності - поставщики і відвідувачі.
Ресторан веде активну діяльність і повсякденно контактує з постачальниками і відвідувачами. Від відвідувачів щодня надходять замовлення, а з постачальниками відбувається обмін документацій про замовлення і надходженнях товару. Обмін інформацією з відвідувачами відбувається при обслуговуванні клієнтів, приймаються їхні замовлення на страви. Постачальники ж безпосередньо контактують з відділом управління фінансами і виробництвом, а так само з кухнею при поставці продуктів. Вся робота ресторану безпосередньо пов'язана з документами - первинна документація, включені в категорію належать рахунки на оплату від постачальників, акти звірок з постачальниками, так само на підприємстві циркулюють такі документи як: рахунки на оплату замовлень, ведеться загальний журнал замовлень, меню ресторану.
Окрему увагу варто приділити надходить і йде інформації при обслуговуванні клієнтів.
Відвідувач вивчає інформацію з меню і на основі її формує своє замовлення. Для розрахунку відвідувача від персоналу кухні приходить інформація про готовність страви. Далі відвідувачеві надходить документ «Рахунок». Відвідувач оплачує рахунок і передає його офіціантові. На основі оплаченого рахунку адміністратор залу формує журнал замовлень і передає його в кінці зміни керівного персоналу.
2.3 Розробка схеми бази даних
Після того як була побудована модель потоків даних, можна приступити до створення схеми даних [5]. Аналізуючи дані діаграми (Малюнок 4) можна виділити два основних сховища даних - меню і замовлення. Ці сховища послужать каркасом схеми бази даних, інформація про дані сутності буде зберігатися у відповідних таблицях («Eda», «Zakaz»). Крім інформації про меню та замовленнях необхідно зберігати дані про користувачів системи, необхідно зберігати інформацію про столиках, а так само інформацію про заброньовані столиках на певну дату. Отже, необхідні ще як мінімум три суті, здатних зберігати необхідну інформацію.
У результаті проведеного аналізу створена модель сутність-зв'язок.
Отримана схема даних дозволяє зберігати всю необхідну інформацію для нормального функціонування ресторану.
2.4 Генерація бази даних
Сучасні CASE-засоби охоплюють велику область підтримки численних технологій проектування інформаційних систем: від простих коштів аналізу та документування до повномасштабних засобів автоматизації, що покривають весь життєвий цикл програмного забезпечення.
Найбільш трудомісткими етапами розробки інформаційних систем є етапи аналізу та проектування, у процесі яких CASE-средства забезпечують якість прийнятих технічних рішень та підготовку проектної документації. При цьому велику роль відіграють методи візуального подання. Це передбачає побудова структурних чи інших діаграм у ре?? льоном масштабі часу, наскрізну перевірку синтаксичних правил. Графічні кошти моделювання предметної області дозволяють розробникам в наочному вигляді вивчати існуючу інформаційну систему, перебудовувати їх у відповідність з поставленими цілями і наявними обмеженнями.
У своїй роботі в якості CASE-засобу був обраний програмний продукт ERwin. ERwin забезпечує генерацію схеми даних сутність-зв'язок у фізичну базу даних. Взаємодія Case-засоби і, в нашому випадку, СУБД Firebird здійснюється засобам використання драйвера ODBC («Open Database Connectivity»). Для коректної генерації схеми даних необхідно внести зміни в т...
