інвентаризація для визначення кількості проданих товарів;
визначення результатів господарської діяльності.
На підставі результатів моніторингу розробляється, у разі потреби, комплекс заходів щодо підвищення якості роботи клієнтських підрозділів і всього магазину в цілому.
2.2 Аналіз потреб
Таблиці:
Поставки. У таблицю поставки вписуються товари, що надходять в той чи інший магазин (№ замовлення, дата поставки, постачальник, назва товару).
Постачальники. У таблицю вписується адреса, телефон та назву організації (номер, назва організації, адреса, телефон).
Товари. У таблицю вписується ціна товару і його кількість (номер, назва товару, категорія, ціна, кількість, запити).
Найближчі товари. У дану таблицю вписуються інформація про товарів, які надійдуть в найближчі час (№ замовлення, дата поставки, постачальник, назва товару).
Товари від 500 рублів - товари з ціною до 500 рублів (номер, назва товару, категорія, ціна, кількість).
Товари категорії А, B, C, D - список товарів за категоріями (номер, назва товару, категорія, ціна, кількість).
Товари від 500 рублів - товари з ціною від 500 рублів (номер, назва товару, категорія, ціна, кількість).
2.3 Побудова ER-діаграми
Типовою формою документування інформаційної моделі предметної області є діаграми «сутність-зв'язок» (ER-діаграми). ER-діаграма дозволяє графічно представити всі елементи інформаційної моделі згідно простим, інтуїтивно зрозумілим, але суворо визначеними правилами - нотаціям. Далі ми будемо користуватися умовними позначеннями, прийнятими в методології інформаційного проектування. Сутність на ER-діаграмі представляється прямокутником з ім'ям у верхній частині. У прямокутнику перераховуються атрибути сутності, при цьому атрибути, складові унікальний ідентифікатор сутності, підкреслюються. Ставлення (зв'язок) сутностей на ER-діаграмі зображується лінією, що з'єднує ці сутності і ромбом з описом відносин. Тип ставлення описується символом у ліній. Це М для множинних відносин і 1 - для одиночних.
2.4 Перетворення ER-діаграми в реляційну модель
Концептуальні моделі дозволяють більш точно уявити предметну область, ніж реляційні та інші більш ранні моделі. Але в даний час існує небагато систем управління базами даних, що підтримують ці моделі. На практиці найбільш поширені системи, що реалізують реляційну модель. Тому необхідний метод перекладу концептуальної моделі в реляційну. Такий метод грунтується на формуванні набору попередніх таблиць з ER-діаграм.
Для кожної сутності створюється таблиця. Причому кожному атрибуту сутності відповідає стовпець таблиці.
Правила генерації таблиць з ER-діаграм спираються на два основні чинники - тип зв'язку і клас приналежності сутності. Викладемо їх:
Правило 1. Якщо зв'язок типу 1: 1 і клас приналежності обох сутностей є обов'язковим, то необхідна тільки одна таблиця. Первинним ключем цієї таблиці може бути первинний ключ кожної із двох сутностей;
Правило 2. Якщо зв'язок типу 1: 1 і клас приналежності однієї сутності є обов'язковим, а другий - необов'язковим, то необхідно побудувати таблицю для кожної сутності. Первинний ключ суті повинен бути первинним ключем відповідної таблиці. Первинний ключ суті, для якої клас приналежності є необов'язковим, додається як атрибут в таблицю для сутності з обов'язковим класом приналежності;
Правило 3. Якщо зв'язок типу 1: 1 і клас приналежності обох сутностей є необов'язковим, то необхідно побудувати три таблиці - по одній для кожної сутності і одну для зв'язку. Первинний ключ суті повинен бути первинним ключем відповідної таблиці. Таблиця для зв'язку серед своїх атрибутів повинна мати ключі обох сутностей;
Правило 4. Якщо зв'язок типу 1: М і клас приналежності сутності на стороні М є обов'язковим, то необхідно побудувати таблицю для кожної сутності. Первинний ключ суті повинен бути первинним ключем відповідної таблиці. Первинний ключ сутності на стороні 1 додається як атрибут в таблицю для сутності на стороні М;
Правило 5. Якщо зв'язок типу 1: М і клас приналежності сутності на стороні М є необов'язковим, то необхідно побудувати три таблиці - по одній для кожної сутності і одну для зв'язку. Первинний ключ суті повинен бути первинним ключем відповідної таблиці. Таблиця для зв'язку серед своїх атрибутів повинна мати ключі обох сутностей;
Правило 6. Якщо зв'язок типу М: N, то нео...
