одель і, відповідно, два рівня моделі. Перший - логічний (точка зору користувача) - описує дані, задіяні в бізнесі підприємства. Другий - фізичний - визначає подання інформації в БД. ERwin об'єднує їх в єдину діаграму, що має кілька рівнів подання.
Фізична модель даних залежить від конкретної СУБД, фактично будучи відображенням системного каталогу. У фізичної моделі міститься інформація про всі об'єкти БД. Оскільки стандартів на об'єкти БД не існує (наприклад, немає стандарту на типи даних), фізична модель залежить від конкретної реалізації СУБД. Отже, однієї і тієї ж логічної моделі можуть відповідати кілька різних фізичних моделей. Якщо в логічній моделі не має значення, який саме тип даних має атрибут, то у фізичній моделі важливо описати всю інформацію про конкретних фізичних об'єктах - таблицях, колонках, індексах, процедурах і т.д. Поділ моделі даних на логічні і фізичні дозволяє вирішити кілька важливих завдань.
Зв'язок багато-до-багатьох можлива тільки на рівні логічної моделі даних, тому при переході до фізичного рівня ERWin автоматично перетворює зв'язок багато-до-багатьох, додаючи нову, асоціативну сутність і встановлюючи дві нові зв'язку один-ко-многим від старих до нової сутності.
При детальному вивченні предметної області мною були виявлені наступні обмеження:
· при розробці використовується багато різної інформації;
· коди інформації, продукції, підприємства, проекту незмінні і унікальні;
· один клієнт може укласти багато договорів.
На малюнку 3.2 представлена ??логічна модель. На ній представлений загальний вигляд потоків інформації. На діаграмі є 5 сутностей:
· Клієнт
· Договір
· Відділ продажу
· Сховище даних
· Звітність
У лівому нижньому куті зображена головна сутність - сховище даних raquo ;, в яку стікається інформація про клієнтів, їх договорах і послуги.
Із сутності клієнт надходять вся інформація про клієнта (ПІБ клієнта, його адресу, контактний телефон, паспортні дані). Із сутності відділу продажів надходить інформація про те, хто з клієнтів уклав договір, які послуги в даний момент може надати відділ продажів і за якою вартістю надається кожна послуга. Із сутності договір надходить інформація про договір клієнта з організацією.
У свою чергу сутність звітність формує різні тіди звітів (список звітів, товарний звіт, облік послуг, підсумковий звіт), які потім надає начальнику відділу продажів і вищестоящим підрозділам організації.
Рис 3.2 Логічна модель
Розроблена структура дозволить зберігати всю необхідну інформацію для коректної роботи модельованої інформаційної системи. У ній є вся необхідна інформація для автоматизації роботи відділу продажів, оформлення документів і розрахунків.
4. Специфікація для створення інформаційної системи відділу продажів Радуга-ТВ
4.1 Склад і принципи інформаційного забезпечення
Основу інформаційного забезпечення ІС становить централізована база даних (ЦБД). Централізована база даних містить повну інформацію для організації відділу продажів. У ЦБД зберігаються дані про хід роботи відділу, що дозволяють вести учет і статистику, формувати різноманітні форми звітності, а також архів готових документів.
Обсяг ініційованих вихідних даних становить 10 Мб.
Ядром системи є централізована база даних реляційного типу, що містить всю інформацію для оперування в різних модулях системи.
Принципи побудови інформаційного забезпечення ІС:
· Інтеграція. Система побудована за модульним принципом на єдиній базі даних, має загальносистемні довідники та класифікатори.
· Функціональна повнота. Система забезпечує інформаційні потреби користувачів, забезпечує підтримку процесів роботи відділу продажів.
· Цілісність. Система підтримує цілісність даних за рахунок транзакційності ведення даних.
· Цілеспрямованість і розмежування доступу. Система включає автоматизовані робочі місця (АРМ) користувачів, в рамках АРМ забезпечується розмежування доступу до даних і функцій системи, система підтримує гнучкі засоби налаштування АРМ і повноважень доступу.
· Відкритість. Система підтримує стандартні протоколи доступу до да...
