Міністерство освіти України
Донбаська Державна Машинобудівна Академія
Контрольна робота
з дисципліни «Інформаційні системи»
2008
1. Стратегії розробки адміністративних інформаційних систем
Адміністративні інформаційні системи (АІС) створюються для здійснення управління і забезпечують нерозривний зв'язок між інформацією та управлінням. Створення АІС - складна проблема. Навіть для дрібних організацій воно передбачає розробку низки підсистем, які повинні відповідати принципам інтеграції та керованості.
Істотний вплив на розроблювану інформаційну модель надає стратегія (або система поглядів) щодо організації системи. На практиці застосовують різні поєднання типових стратегій або підходів
Загальносистемний підхід.
Загальносистемний підхід грунтується на припущенні, що ще до реалізації системи ми деяким обгрунтованим способом можемо розпізнати взаємозв'язку між частинами її базової інформації. Процеси збору, зберігання і обробки даних проектуються і реалізуються в рамках всієї системи в цілому. Хоча цей підхід є ідеальним, його застосування в повному обсязі може виявитися досить важким через практичних, політичних, соціальних проблем. При вже існуючій системі проектування ідеальної системи може стати просто академічним вправою, тому що її реалізація викличе радикальні перетворення. У самому справі, сліпе, без певної технології, використання проектувальниками цього підходу може призвести до краху ілюзій, що і трапляється у багатьох сьогоднішніх обчислювальних системах. Однак, в організаціях, які ще не мають розроблених систем, що діють і вважаються задовільними, розглянутий підхід може бути успішно застосований. Він є ідеалізованим і не може в повному обсязі застосовуватися в реальної організації.
Як можна було побачити при розгляді шести підходів, стратегія вибору підходу має формуватися з урахуванням особливостей конкретної системи. Слід брати до уваги такі чинники, як розмір організації, природа її ділових операцій та досвід. Істотно, що вибір стратегії має бути зроблений після ретельної оцінки ступеня ризику і переваг можливих підходів.
2. Нормалізація і нормальні форми при розробці баз даних
Центральна задача проектування бази даних ЕІС-визначення кількості відносин (або інших складових одиниць інформації) та його атрибутного складу.
Завдання угруповання атрибутів у відносини, набір яких заздалегідь не фіксований, допускає безліч різних варіантів рішень. Раціональні варіанти угрупування повинні враховувати наступні вимоги:
• безліч відносин має забезпечувати мінімальну надмірність подання інформації,
• коректування відносин не повинна приводити до двозначності або втрати інформації,
• перебудова набору відносин при додаванні в базуданних нових атрибутів повинна бути мінімальною.
Нормалізація являє собою один з найбільш вивчених способів перетворення відносин, що дозволяють поліпшити характеристики БД по перерахованим критеріям.
Обмеження на значення, що зберігаються у реляційній базі даних, досить численні. Дотримання цих обмежень у конкретних відносинах пов'язано з наявністю так званих нормальних форм. Процес перетворення відносин бази даних до тієї чи іншої нормальної формі називається нормалізацією відносин. Нормальні форми нумеруються послідовно від 1 по зростанню, і чим більше номер нормальної форми, тим більше обмежень на збережені значення має дотримуватися відповідного ставлення.
Обмеження, типові для реляційної моделі даних,-це функціональні та багатозначні залежності, а також їх узагальнення. У принципі, безліч додаткових обмежень може рости і відповідно буде збільшуватися число нормальних форм. Застосовувані обмеження орієнтовані на скорочення надлишкової інформації в реляційної базі даних.
Ставлення в першій нормальній формі (скорочено 1НФ) - це звичайне ставлення з дворівневою структурою. Неприпустимість в структурі відносини третього і наступних рівнів є обмеженням, визначальним 1НФ відносини.
Перетворення ненормалізованном відносини в уявлення, яка відповідає 1 НФ, - це операція нормалізації, розглянута вище. Слід відзначити певне термінологічне невідповідність - нормалізація ЦЕЙ при-"водить до 1НФ, а нормалізація відносин реляційної БД звичайно проводиться до ЗНФ або 4НФ.
Реляційна база даних в цілому характеризується 1НФ, якщо всі її відносини відповідають 1НФ.
Наступні нормальні форми "(друга і третя) використовують обмеження, пов'язані з поняттям функціональної залежності, яке необхідно попередньо розглянути.
Функціональні залежності і ключі
Функціональні залежності визначаються для атрибутів, які знаходяться в одному і тому ж відношенні, що задовольняє 1НФ.
Найпростіший випадок функціональної залежності охоплює 2 атрибуту. У відношенні R (A, B ,...) атрибут А функціонально визначає атрибут В, якщо у будь-який момент часу кожному значенню А відповідає єдине значення В (позначається А -> В).
Інакше говорять, що В функціонально залежить від А (позначається В = f (A)). Перше позначення виявляється більш зручним, коли число функціональних залежностей зростає і їх взаємозв'язку стають труднообозримой; воно і буде використовуватися надалі. Відсутність функціональної залежності позначається А - / -> В.
Можна визначити ситуацію А -> В за допомогою операції "образ", сказавши що безліч in B (а) повинна містити один елемент для будь-якого значення а атрибуту А.
Розглянемо кілька прикладів:
Приклад № 1.Прізвище студента, група. Показує залежність А -> В (або В -> А), але не обидві залежно разом
Приклад № 2 Магазин і розрахунковий рахунок. Наявність взаємно-однозначного відповідності А <-> В.
Приклад № 3 Студент, Дисципліна. Відсутність функціональної залежності.
Поняття функціональної залежності поширюється на ситуацію з трьома і більше атрибутами в такій формі. Група атрибутів (для визначеності А, В, С) функціонально визначає атрибут D відносно T (A, B, C, D ,....), якщо кожному поєднанню значень <a,b,c> відповідає єдине значення d (а - значення A, b - значення В, с - значення С, d - значення D). Наявність такої функціональної залежності будемо позначати А, В, С -> D. Випадок, коли у правій частині функціональної залежності присутні кілька атрибутів, не потребує спеціального розгляду. Взаємно-однозначні відповідності для трьох і більше атрибутів також не мають самостійного значення.
Неувага до способів кодування атрибутів може призвести до невідповідності функціональних залежностей та збережених даних, що є серйозною проектної помилкою.
За допомогою функціональних залежностей визначається поняття ключа відносини, точніше ряд різновидів ключів - ймовірні, первинні і вторинні.
Ймовірним ключем відносини називається така безліч атрибутів, що кожне поєднання їх значень зустрічається тільки в одному рядку відносини, і ніяке підмножина атрибутів цією властивістю не володіє. Вірогідних ключів в відношенні може бути декілька.
Важливість ймовірних ключів при обробці даних визначається тим, що вибірка за відомим значенням ймовірного ключа дає в результаті один рядок відносини або жодної.
На практиці атрибути ймовірного ключа відносини зв'язуються з властивостями тих об'єктів і подій, інформація про яких зберігається у відношенні. Якщо в результаті коригування відносини змінилися імена атрибутів, створюючих ключ, то це свідчить про серйозний спотворенні інформації. Отже, систематична перевірка властивостей ймовірного ключа дозволяє стежити за достовірністю інформації у відношенні.
Якщо стосовно присутні кілька ймовірних ключів, одночасне спостереження за ними дуже ускладнене і доцільно вибрати один з них в якості основного (первинного).
Первинним ключем відносини називається такий імовірний ключ, за значеннями якого проводиться контроль достовірності інформації у відношенні.
Що стосується економічної інформації в переважній більшості випадків відносини, отримані з існуючих економічних документів, містять єдиний ймовірний ключ, який є і первинним ключем. Це пояснюється тим, що вміст економічних документів розуміється всіма користувачами однаково. Далі будемо мати на увазі лише такі відносини. Наявність двох і більше ймовірних ключів у відносинах з осмисленої інформацією можна пояснити наявністю кількох можливих способів інтерпретації одних і ті х ж даних. Первинний ключ часто називається просто ключ.
Кожне значення первинного ключа зустрічається тільки в одному рядку відносини. Значення будь-якого атрибута в цьому рядку також єдине. Якщо через До позначити атрибути первинного ключа в відношенні (А, В, С ,..., J), то справедливі наступні функціональні залежності К -> А, К -> В, К -> З ,..., К -> J. Набір атрибутів первинного ключа функціонально визначає будь-який атрибут о> носіння. Зворотне також вірно: якщо знайдена група атрибутів, яка функціонально визначає всі атрибути ставлення окремо, і цю групу не можна скоротити, то знайдений первинний ключ відносини.
Для безлічі функціональних залежностей існує ряд закономірностей, які виражаються теоремами. Знання теорем дозволяє з вихідної безлічі функціональних залежностей отримувати похідні залежності.
Відзначимо ряд відомих теорем про функціональні залежності. Атрибути, що фігурують в кожній теоремі, повинні знаходитися в одному і тому ж відношенні.
Теорема 1
А, В -* А і А, В -> В.
Доказ засноване на тому, що в рядку <а, Ь> для атрибутів А і В значення а (як і значення Ь) присутній один раз.
Теорема 2
А -> В і А -> З тоді і тільки тоді, коли А -> НД
Розглянемо довільне значення а атрибуту А. Якщо А -> В і А -* С, то im В (а) і im C (a) містять по одному елементу. Припустимо, що залежність А -> НД невірна і ini ПС (а) складається з 2 Іди більше елементів. Тоді або im B (a), або im C (a) повинні містити більше одного елемента. Отримане протиріччя доводить залежність А -> НД
Зворотно, якщо А -> ЗС, то im BC (a) містить один елемент виду <Т, з> для будь-якого а. Зафіксуємо деяке значення al. Значення b (як і значення з) зустрічається в поєднанні з д! тільки один раз, отже, справедливо А -> В і А -> С.
Теорема 3
Якщо А -> "В і В -> С, то А -> С.
Припустимо, що залежність А -> З невірна і безліч im С (а) містить більше одного елемента. Кожному значенню а відповідає єдине значення b (в силу А -> В), тому im C (b) містить більше одного елемента. Вийшло протиріччя з умовою В -> С, що і доводить теорему.
Примітно, що докази інших теорем спираються на перші 3 теореми, а не доводяться від протилежного.
Теорема 4
Якщо А-»В, то АС -> В (С довільно).
Доказ
АС -> А (теорема 1), А -> В (умова), отже, АС -> В за теоремою 3.
Теорема 5
Якщо А -> В, то АС -> ВС (З довільно).
Доказ
АС - »В (теорема 4), АС -» С (теорема 1), отже, АС-> ПС за теоремі 2.
Теорема 6
Якщо А -> В і ВС -> D, то АС -* D.
Доказ
З А -> В слід АС -> ВС (теорема 5). ВС -> D (умова), тому АС-> D по теоремі 3.
Друга і третя нормальні форми відносин
Ставлення має другу нормальну форму (2НФ), якщо воно відповідає 1НФ і не містить неповних функціональних залежностей.
Неповна функціональна залежність - це дві залежності:
· Ймовірний ключ відносини функціонально визначає певний неключових атрибут,
· Частина ймовірного ключа функціонально визначає цей же неключових атрибут.
Відношення, що не відповідає 2НФ, характеризується надмірністю збережених даних.
Наприклад:
Функціональні залежності відносини Т4:
Надмірність ілюструється тим фактом, що ціна виробу вказується стільки разів, скільки магазинів продають цей виріб (виріб М22 в Т4). Перехід до 2НФ і відповідно усунення зазначеної надмірності даних пов'язано зі створенням двох відносин замість вихідного відносини Т4.
Ставлення відповідає ЗНФ, якщо воно відповідає 2НФ і серед його атрибутів відсутні транзитивні функціональні залежності (ФЗ).
Алгоритм отримання відносин у ЗНФ володіє наступними властивостями:
· Зберігає всі початкові функціональні залежності, тобто залежність, справедлива в R, справедлива і в одному з похідних відносин. Це гарантує отримання осмислених відносин з легко інтерпретується структурою;
· Забезпечує з'єднання без втрат, тобто значення вихідного відношення R можуть бути відновлені з проекцій відносини R з допомогою операції сполуки;
· Результат декомпозиції в ЗНФ зазвичай містить менше значень атрибутів, ніж вихідне відношення R (відбувається зменшення надмірності).
3. Розробити інформаційну систему для обліку витрат на виробництво продукції
Дане завдання необхідна для планово-економічного відділу підприємства. Її мета показати витрати на виробництво з урахуванням матеріальних і трудових ресурсів. Результати завдання показують наскільки вигідно для підприємства виконання даного замовлення виготовлення продукції. Дані про необхідну інформації надходять з таких відділів беруть участь в процесі обробки інформації:
· Фінансовий;
· Відділу матеріалів;
· Комплектуючий відділ;
· Розрахунковий відділ;
· Ін
Необхідність або періодичність виконання даного завдання залежить від кількості виконуваних замовлень. Іншими словами, вона необхідна при виконанні будь-якого замовлення, що виконується на підприємстві.
Наведені вхідні дані мають укрупнений вигляд.
Вхідні таблиці:
1. Зведена таблиця обліків замовлень. (Costs)
Донбаська Державна Машинобудівна Академія
Контрольна робота
з дисципліни «Інформаційні системи»
2008
1. Стратегії розробки адміністративних інформаційних систем
Адміністративні інформаційні системи (АІС) створюються для здійснення управління і забезпечують нерозривний зв'язок між інформацією та управлінням. Створення АІС - складна проблема. Навіть для дрібних організацій воно передбачає розробку низки підсистем, які повинні відповідати принципам інтеграції та керованості.
Істотний вплив на розроблювану інформаційну модель надає стратегія (або система поглядів) щодо організації системи. На практиці застосовують різні поєднання типових стратегій або підходів
Загальносистемний підхід.
Загальносистемний підхід грунтується на припущенні, що ще до реалізації системи ми деяким обгрунтованим способом можемо розпізнати взаємозв'язку між частинами її базової інформації. Процеси збору, зберігання і обробки даних проектуються і реалізуються в рамках всієї системи в цілому. Хоча цей підхід є ідеальним, його застосування в повному обсязі може виявитися досить важким через практичних, політичних, соціальних проблем. При вже існуючій системі проектування ідеальної системи може стати просто академічним вправою, тому що її реалізація викличе радикальні перетворення. У самому справі, сліпе, без певної технології, використання проектувальниками цього підходу може призвести до краху ілюзій, що і трапляється у багатьох сьогоднішніх обчислювальних системах. Однак, в організаціях, які ще не мають розроблених систем, що діють і вважаються задовільними, розглянутий підхід може бути успішно застосований. Він є ідеалізованим і не може в повному обсязі застосовуватися в реальної організації.
Як можна було побачити при розгляді шести підходів, стратегія вибору підходу має формуватися з урахуванням особливостей конкретної системи. Слід брати до уваги такі чинники, як розмір організації, природа її ділових операцій та досвід. Істотно, що вибір стратегії має бути зроблений після ретельної оцінки ступеня ризику і переваг можливих підходів.
2. Нормалізація і нормальні форми при розробці баз даних
Центральна задача проектування бази даних ЕІС-визначення кількості відносин (або інших складових одиниць інформації) та його атрибутного складу.
Завдання угруповання атрибутів у відносини, набір яких заздалегідь не фіксований, допускає безліч різних варіантів рішень. Раціональні варіанти угрупування повинні враховувати наступні вимоги:
• безліч відносин має забезпечувати мінімальну надмірність подання інформації,
• коректування відносин не повинна приводити до двозначності або втрати інформації,
• перебудова набору відносин при додаванні в базуданних нових атрибутів повинна бути мінімальною.
Нормалізація являє собою один з найбільш вивчених способів перетворення відносин, що дозволяють поліпшити характеристики БД по перерахованим критеріям.
Обмеження на значення, що зберігаються у реляційній базі даних, досить численні. Дотримання цих обмежень у конкретних відносинах пов'язано з наявністю так званих нормальних форм. Процес перетворення відносин бази даних до тієї чи іншої нормальної формі називається нормалізацією відносин. Нормальні форми нумеруються послідовно від 1 по зростанню, і чим більше номер нормальної форми, тим більше обмежень на збережені значення має дотримуватися відповідного ставлення.
Обмеження, типові для реляційної моделі даних,-це функціональні та багатозначні залежності, а також їх узагальнення. У принципі, безліч додаткових обмежень може рости і відповідно буде збільшуватися число нормальних форм. Застосовувані обмеження орієнтовані на скорочення надлишкової інформації в реляційної базі даних.
Ставлення в першій нормальній формі (скорочено 1НФ) - це звичайне ставлення з дворівневою структурою. Неприпустимість в структурі відносини третього і наступних рівнів є обмеженням, визначальним 1НФ відносини.
Перетворення ненормалізованном відносини в уявлення, яка відповідає 1 НФ, - це операція нормалізації, розглянута вище. Слід відзначити певне термінологічне невідповідність - нормалізація ЦЕЙ при-"водить до 1НФ, а нормалізація відносин реляційної БД звичайно проводиться до ЗНФ або 4НФ.
Реляційна база даних в цілому характеризується 1НФ, якщо всі її відносини відповідають 1НФ.
Наступні нормальні форми "(друга і третя) використовують обмеження, пов'язані з поняттям функціональної залежності, яке необхідно попередньо розглянути.
Функціональні залежності і ключі
Функціональні залежності визначаються для атрибутів, які знаходяться в одному і тому ж відношенні, що задовольняє 1НФ.
Найпростіший випадок функціональної залежності охоплює 2 атрибуту. У відношенні R (A, B ,...) атрибут А функціонально визначає атрибут В, якщо у будь-який момент часу кожному значенню А відповідає єдине значення В (позначається А -> В).
Інакше говорять, що В функціонально залежить від А (позначається В = f (A)). Перше позначення виявляється більш зручним, коли число функціональних залежностей зростає і їх взаємозв'язку стають труднообозримой; воно і буде використовуватися надалі. Відсутність функціональної залежності позначається А - / -> В.
Можна визначити ситуацію А -> В за допомогою операції "образ", сказавши що безліч in B (а) повинна містити один елемент для будь-якого значення а атрибуту А.
Розглянемо кілька прикладів:
Приклад № 1.Прізвище студента, група. Показує залежність А -> В (або В -> А), але не обидві залежно разом
| R1 | |
| ПІБ | ГР |
| Іванов Зуєв Смирнов Яшина | 1960 1963 1960 1961 |
| R2 | |
| Магазин | Розр |
| ММЗ | 704098 |
| Динамо АТЕ | 122095 440162 |
| R3 | |
| ПІБ | Дисципліна |
| Петров Федін Альошин Петров | Фізика Хімія Фізика Хімія |
Неувага до способів кодування атрибутів може призвести до невідповідності функціональних залежностей та збережених даних, що є серйозною проектної помилкою.
За допомогою функціональних залежностей визначається поняття ключа відносини, точніше ряд різновидів ключів - ймовірні, первинні і вторинні.
Ймовірним ключем відносини називається така безліч атрибутів, що кожне поєднання їх значень зустрічається тільки в одному рядку відносини, і ніяке підмножина атрибутів цією властивістю не володіє. Вірогідних ключів в відношенні може бути декілька.
Важливість ймовірних ключів при обробці даних визначається тим, що вибірка за відомим значенням ймовірного ключа дає в результаті один рядок відносини або жодної.
На практиці атрибути ймовірного ключа відносини зв'язуються з властивостями тих об'єктів і подій, інформація про яких зберігається у відношенні. Якщо в результаті коригування відносини змінилися імена атрибутів, створюючих ключ, то це свідчить про серйозний спотворенні інформації. Отже, систематична перевірка властивостей ймовірного ключа дозволяє стежити за достовірністю інформації у відношенні.
Якщо стосовно присутні кілька ймовірних ключів, одночасне спостереження за ними дуже ускладнене і доцільно вибрати один з них в якості основного (первинного).
Первинним ключем відносини називається такий імовірний ключ, за значеннями якого проводиться контроль достовірності інформації у відношенні.
Що стосується економічної інформації в переважній більшості випадків відносини, отримані з існуючих економічних документів, містять єдиний ймовірний ключ, який є і первинним ключем. Це пояснюється тим, що вміст економічних документів розуміється всіма користувачами однаково. Далі будемо мати на увазі лише такі відносини. Наявність двох і більше ймовірних ключів у відносинах з осмисленої інформацією можна пояснити наявністю кількох можливих способів інтерпретації одних і ті х ж даних. Первинний ключ часто називається просто ключ.
Кожне значення первинного ключа зустрічається тільки в одному рядку відносини. Значення будь-якого атрибута в цьому рядку також єдине. Якщо через До позначити атрибути первинного ключа в відношенні (А, В, С ,..., J), то справедливі наступні функціональні залежності К -> А, К -> В, К -> З ,..., К -> J. Набір атрибутів первинного ключа функціонально визначає будь-який атрибут о> носіння. Зворотне також вірно: якщо знайдена група атрибутів, яка функціонально визначає всі атрибути ставлення окремо, і цю групу не можна скоротити, то знайдений первинний ключ відносини.
Для безлічі функціональних залежностей існує ряд закономірностей, які виражаються теоремами. Знання теорем дозволяє з вихідної безлічі функціональних залежностей отримувати похідні залежності.
Відзначимо ряд відомих теорем про функціональні залежності. Атрибути, що фігурують в кожній теоремі, повинні знаходитися в одному і тому ж відношенні.
Теорема 1
А, В -* А і А, В -> В.
Доказ засноване на тому, що в рядку <а, Ь> для атрибутів А і В значення а (як і значення Ь) присутній один раз.
Теорема 2
А -> В і А -> З тоді і тільки тоді, коли А -> НД
Розглянемо довільне значення а атрибуту А. Якщо А -> В і А -* С, то im В (а) і im C (a) містять по одному елементу. Припустимо, що залежність А -> НД невірна і ini ПС (а) складається з 2 Іди більше елементів. Тоді або im B (a), або im C (a) повинні містити більше одного елемента. Отримане протиріччя доводить залежність А -> НД
Зворотно, якщо А -> ЗС, то im BC (a) містить один елемент виду <Т, з> для будь-якого а. Зафіксуємо деяке значення al. Значення b (як і значення з) зустрічається в поєднанні з д! тільки один раз, отже, справедливо А -> В і А -> С.
Теорема 3
Якщо А -> "В і В -> С, то А -> С.
Припустимо, що залежність А -> З невірна і безліч im С (а) містить більше одного елемента. Кожному значенню а відповідає єдине значення b (в силу А -> В), тому im C (b) містить більше одного елемента. Вийшло протиріччя з умовою В -> С, що і доводить теорему.
Примітно, що докази інших теорем спираються на перші 3 теореми, а не доводяться від протилежного.
Теорема 4
Якщо А-»В, то АС -> В (С довільно).
Доказ
АС -> А (теорема 1), А -> В (умова), отже, АС -> В за теоремою 3.
Теорема 5
Якщо А -> В, то АС -> ВС (З довільно).
Доказ
АС - »В (теорема 4), АС -» С (теорема 1), отже, АС-> ПС за теоремі 2.
Теорема 6
Якщо А -> В і ВС -> D, то АС -* D.
Доказ
З А -> В слід АС -> ВС (теорема 5). ВС -> D (умова), тому АС-> D по теоремі 3.
Друга і третя нормальні форми відносин
Ставлення має другу нормальну форму (2НФ), якщо воно відповідає 1НФ і не містить неповних функціональних залежностей.
Неповна функціональна залежність - це дві залежності:
· Ймовірний ключ відносини функціонально визначає певний неключових атрибут,
· Частина ймовірного ключа функціонально визначає цей же неключових атрибут.
Відношення, що не відповідає 2НФ, характеризується надмірністю збережених даних.
Наприклад:
| Т4 | |||
| Магазин | Виріб | Ціна | План_1999_г. |
| Салют | М22 | 50 | 200 |
| Салют | К14 | 40 | 100 |
| АТЕ | М22 | 50 | 300 |
| АТЕ | Т62 | 60 | 100 |
Надмірність ілюструється тим фактом, що ціна виробу вказується стільки разів, скільки магазинів продають цей виріб (виріб М22 в Т4). Перехід до 2НФ і відповідно усунення зазначеної надмірності даних пов'язано зі створенням двох відносин замість вихідного відносини Т4.
| Т41 | ||
| Магазин | Виріб | План_1999_г. |
| Салют Салют АТЕ АТЕ | М22 К14 М22 Т62 | 200 100 300 100 |
| Т42 | |
| Виріб | Ціна |
| М22 К14 Т62 | 50 40 60 |
Алгоритм отримання відносин у ЗНФ володіє наступними властивостями:
· Зберігає всі початкові функціональні залежності, тобто залежність, справедлива в R, справедлива і в одному з похідних відносин. Це гарантує отримання осмислених відносин з легко інтерпретується структурою;
· Забезпечує з'єднання без втрат, тобто значення вихідного відношення R можуть бути відновлені з проекцій відносини R з допомогою операції сполуки;
· Результат декомпозиції в ЗНФ зазвичай містить менше значень атрибутів, ніж вихідне відношення R (відбувається зменшення надмірності).
3. Розробити інформаційну систему для обліку витрат на виробництво продукції
Дане завдання необхідна для планово-економічного відділу підприємства. Її мета показати витрати на виробництво з урахуванням матеріальних і трудових ресурсів. Результати завдання показують наскільки вигідно для підприємства виконання даного замовлення виготовлення продукції. Дані про необхідну інформації надходять з таких відділів беруть участь в процесі обробки інформації:
· Фінансовий;
· Відділу матеріалів;
· Комплектуючий відділ;
· Розрахунковий відділ;
· Ін
Необхідність або періодичність виконання даного завдання залежить від кількості виконуваних замовлень. Іншими словами, вона необхідна при виконанні будь-якого замовлення, що виконується на підприємстві.
Наведені вхідні дані мають укрупнений вигляд.
Вхідні таблиці:
1. Зведена таблиця обліків замовлень. (Costs)
| Найменування поля | Ідентифікація | Тип даних |
| Код запису (ключове) | ID | Лічильник |
| Код замовлення | KodZak | Текстове |
| Дата | Data | Дата / час |
| Витрати на матеріали | Materials | Грошовий |
| Витрати на доп. матеріали | SumMaterials | Грошовий |
| Накладні витрати | Overheads | Грошовий |
| Напівфабрикати / комплектуючі | SemiProducts | Грошовий |
2. Таблиця обліку роботи над замовленням фахівців (MainManufacture)
3. Таблиця обліку роботи над замовленням груп працівників (SubManufacture)
4. Таблиця працівників-фахівців (WorkersList)
Побудуємо схему даних.
Як видно з таблиць, всі вони мають ключові поля (ID) які вказують на унікальність запису в будь-якій з таблиць. Так, в таблицях 2 і 3 існують поля ID_Costs, які вказують на певне замовлення. Дана умова було необхідно, оскільки унікальним ключем таблиці COSTS є номер замовлення і дата його запуску. Дані поля разом представляють досить велике поле-ключ, що буде створювати в інших таблицях надмірність інформації. Отже, досить таки зручніше ввести одне унікальне поле, яке і буде служити ключем для зв'язки таблиць. Теж саме стосується і Таблиці WorkersList. Як правило, унікальним може бути і табельний номер працівника, але є випадки, коли він не унікальний: наприклад, табельні номери кожен раз починаються з початку в новому відділі, або це поле має літерно-цифровий вигляд, що призводить до збільшення обробки інформації, оскільки комп'ютерна техніка працює швидше з цифрами, ніж з символами.
Уявімо дані таблиць на прикладі.
Costs.
MainManufacture
SubManufacture
WorkersList
У ході роботи були створені запити, які, грунтуючись на дані таблиць розраховують проміжні дані для зведеного звіту.
Запит "Зарплата фахівців" - розраховує дані (заробітну плату) фахівців за всіма виконаним замовленням. Це другорядні дані які можуть бути отримані для працівників розрахункового відділу.
Запит Calc_Main - розраховує дані (заробітну плату) за замовленнями про участь фахівців у процесі виконання замовлення.
Запит Calc_Sub - розраховує дані (заробітну плату) за замовленнями про участь робітників у процесі виконання замовлення.
Вихідними даними буде зведена таблиця / звіт про виконання всіх замовлень з урахуванням витрат на виплату заробітної плати, а також підсумковими сумами за замовленням.
Звіт про витрати на виробництво
| Найменування поля | Ідентифікація | Тип даних |
| Код запису (ключове) | ID | Лічильник |
| Код замовлення | ID_costs | Числове-ціле |
| Код робочого | WorkerID | Числове-ціле |
| Заробітна плата | Zarpl | Грошовий |
| Найменування поля | Ідентифікація | Тип даних |
| Код запису (ключове) | ID | Лічильник |
| Код замовлення | ID_Costs | Числове-ціле |
| Кількість працівників | Kolvo | Числове-ціле |
| Середня заробітна плата | AvrZarpl | Грошовий |
| Найменування поля | Ідентифікація | Тип даних |
| Код запису (ключове) | ID | Лічильник |
| Табельний номер | TabNo | Числове-ціле |
| Прізвище, І.О. | FIO | Текстове |
Побудуємо схему даних.
|
| ||||||||||||
| Data | ||||||||||||
| Materials | ||||||||||||
| SumMaterials | ||||||||||||
| ||||||||||||
| SemiProducts |
Уявімо дані таблиць на прикладі.
Costs.
| ID | KodZak | Data | Materials | SubMaterials | overheads | SemiProducts |
| 1 | 11-1 | 01.01.2003 | 10 000,00 грн. | Серпні 000,00 грн. | 2 000,00 грн. | 3 000,00 грн. |
| 2 | 22-2 | 01.10.2003 | 12 000,00 грн. | 7 500,00 грн. | 2 200,00 грн. | 3 500,00 грн. |
| 3 | 33-3 | 01.11.2003 | 12 250,00 грн. | Серпні 800,00 грн. | 2 300,00 грн. | 3 300,00 грн. |
| ID | ID_Costs | WorkerID | Zarpl |
| 1 | 1 | 1 | 300,00 грн. |
| 2 | 1 | 2 | 310,00 грн. |
| 3 | 2 | 3 | 325,00 грн. |
| 4 | 2 | 2 | 315,00 грн. |
| 5 | 3 | 1 | 300,00 грн. |
| 6 | 3 | 3 | 320,00 грн. |
| ID | ID_Costs | Kolvo | AvrZarpl |
| 1 | 1 | 5 | 200,00 грн. |
| 2 | 2 | 7 | 250,00 грн. |
| 3 | 3 | 10 | 180,00 грн. |
| 4 | 1 | 6 | 175,00 грн. |
| ID | TabNo | FIO |
| 1 | 123 | Іванов І.І. |
| 2 | 124 | Петров П.П. |
| 3 | 125 | Сидоров С.С. |
Запит "Зарплата фахівців" - розраховує дані (заробітну плату) фахівців за всіма виконаним замовленням. Це другорядні дані які можуть бути отримані для працівників розрахункового відділу.
| TabNo | FIO | Sum_Zarpl |
| 123 | Іванов І.І. | 600,00 грн. |
| 124 | Петров П.П. | 625,00 грн. |
| 125 | Сидоров С.С. | 645,00 грн. |
| toMainBills | ID_Costs |
| 610,00 грн. | 1 |
| 640,00 грн. | 2 |
| 620,00 грн. | 3 |
| toSubBills | ID_Costs |
| 2 050,00 грн. | 1 |
| 1 750,00 грн. | 2 |
| 1 800,00 грн. | 3 |
Звіт про витрати на виробництво
| Код замовлення | Дата замовлення | Матеріали | Непередбачені витрати | Полуфабрі-кати | Заробітна плата | Разом | ||
| Основні | Допоміжним тільні | Спеціа-листи | Робітники | |||||
| 11-1 | 01.01.2003 | 10 000,00 грн. | Серпні 000,00 грн. | 2 000,00 грн. | 3 000,00 грн. | 610,00 грн. | 2 050,00 грн. | 25 660,00 грн. |
| 22-2 | 01.10.2003 | 12 000,00 грн. | 7 500,00 грн. | 2 200,00 грн. | 3 500,00 грн. | 640,00 грн. | 1 750,00 грн. | 27 590,00 грн. |
| 33-3 | 01.11.2003 | 12 250,00 грн. | Серпні 800,00 грн. | 2 300,00 грн. | 3 300,00 грн. | 620,00 грн. | 1 800,00 грн. | 29 070,00 грн. |