База даних стоматологічного кабінету

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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