База даних "Облік діяльності Ощадбанку"

Для кожного зовнішнього ключа відношення варто вказати умови, що повинні виконуватися при відновленні або видаленні відповідного значення первинного ключа. У цьому випадку можна застосувати одну з пропонованих стратегій - NO ACTION, CASCADE, SET NULL, SET DEFAULT або NO CHECK.

Вимоги даного філіалу

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

Етап 2.4 Обговорення розроблених локальних логічних моделей даних з кінцевими користувачами

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

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

Рис.7. Локальна концептуальна модель даних для користувача завідувач відділу грошових внесків.

Етап 3. Створення і перевірка глобальної логічної моделі даних

Етап 3.1 Злиття локальних логічних моделей даних у єдину глобальну модель даних

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

Аналіз імен сутностей і їхніх первинних ключів

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

Таблиця 2.1 Порівняння імен сутностей і їхніх первинних ключів у представленнях користувачів економіст і завідувач відділу

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

Аналіз імен зв'язків

Тепер порівняємо імена присутніх у представленнях економіст і завідувач відділу зв'язків. Імена зв'язків, що існують у кожному із представлень, показані в табл.2.2 Кожен зв'язок представлений у таблиці тільки один раз і асоційований з її батьківською сутністю.

Таблиця 2.2 Порівняння зв'язків, наявних у представленнях економіст і завідувач.

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

Злиття загальних сутностей з окремих локальних моделей

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

злиття сутностей з однаковими іменами й однаковими первинними ключами;

злиття сутностей з однаковими іменами, що мають різні первинні ключі;

злиття сутностей з різними іменами, що мають однакові або різні первинні ключі.

Злиття сутностей з однаковими іменами й однаковими первинними ключами.

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

Лістинг 2.1 Злиття сутностей економіст відділу грошових внесків з представлень завідувач відділу.

Представлення економіст відділу грошових внесків

ЕКОНОМІСТ (Номер_економіста, Прізвище, Ім'я, Адреса, Телефон, Стать, Дата народження)

Первинний ключ - Номер_Працівника.

Зовнішній ключ - Номер_філіалу посилання Служба роботи банку.

Представлення завідуючий відділу грошових внесків

ЗАВІДУЮЧИЙ ВІДДІЛУ (Номер_зав. відділу, Прізвище, Ім'я, Адреса, Телефон, Стать, Дата народження, № філіалу).

Первинний ключ - Номер_зав. відділу.

Альтернативний ключ - № філіалу.

Зовнішній ключ - Служба роботи банку посилання Служба роботи банку).

Глобальне представлення

ПРАЦІВНИК Номер_Працівника, Прізвище, Ім'я, Адреса, Телефон, Стать, Дата народження, Дата прийняття, № філіалу

Первинний ключ - Номер_Працівника.

Альтернативний ключ - № філіалу.

Зовнішній ключ - Служба роботи банку посилання Служба роботи банку.

Аналогічно злиття робиться для всіх інших сутностей.

Злиття сутностей з однаковими іменами, що мають різні первинні ключі.

Такі сутності відсутні.

Злиття сутностей з різними іменами, що мають однакові або різні первинні ключі

Такі сутності відсутні

Включення (без злиття) сутностей, унікальних для кожного локального представлення

Такі сутності відсутні.

Злиття загальних зв'язків з окремих локальних моделей

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

Включення (без злиття) зв'язків, унікальних для кожного локального представлення

У табл.2.2 можна виділити зв'язки, що є унікальними для кожного з представлень. Ці зв'язки повинні бути перенесені в глобальну модель даних без яких-небудь змін.

Перевірка на наявність пропущених сутностей і зв'язків.

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

Перевірка коректності зовнішніх ключів.

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

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

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

Виконання креслення глобальної логічної моделі даних.

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

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

Відновлення документації.

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

Етап 3.2 Перевірка глобальної логічної моделі даних

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

Етап 3.3 Створення остаточного варіанта діаграми „сутність - зв'язок"

У нашому навчальному прикладі не треба було вносити змін або доповнень у вихідний варіант ER-діаграми, показаний на рис.14. Цей варіант діаграми є остаточною версією логічного глобального представлення предметної області "АТП".

Рис.9. Глобальне представлення предметної області діяльності АТП

Етап 3.4 Обговорення глобальної логічної моделі даних з користувачами

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

Висновки