2. : аналіз конкретного випадку
2.1. Проблема
Повернімося до додатка, який ми хочемо створити. Ми беремо за основу існуючий додаток із такою архітектурою:
 |
Для тих, хто хоче дізнатися більше про:
- NHibernate: Вступ до ORM Nhibernate [http://tahe.developpez.com/dotnet/nhibernate/];
- додаток ASP.NET (WebForms) із NHibernate та Spring: Створення трирівневого веб-додатку з використанням ASP.NET, Spring.NET, NHibernate та [http://tahe.developpez.com/dotnet/pam-aspnet/].
Ми хочемо перетворити попередній додаток на такий:
 |
де EF5 замінило NHibernate. Цей додаток є приводом для вивчення EF5. Оскільки Spring.NET дозволяє нам легко змінювати шар, не порушуючи загальної роботи, додаток 2 використовуватиме той самий шар [ASP.NET], що й додаток 1. Оскільки цей документ присвячений EF5, ми не будемо пояснювати, як написати цей шар. Ми просто підключимо його до додатка 2, щоб переконатися, що все працює. Ми лише пояснимо, які зміни потрібно внести у файл конфігурації Spring.NET.
Приклад із практики такий. Ми хочемо запропонувати лікарям сервіс запису на прийом, що працює за таким принципом:
- секретаріат забезпечує прийом RV для великої кількості лікарів. Ця служба може складатися лише з однієї особи. Її заробітна плата розподіляється між усіма лікарями, які користуються послугою RV;
- секретарська служба та всі лікарі підключені до Інтернету;
- записи RV зберігаються в централізованій базі даних, доступ до якої через Інтернет мають секретаріат та лікарі;
- призначення RV зазвичай здійснює секретаріат. Це також можуть робити самі лікарі. Зокрема, це відбувається тоді, коли наприкінці прийому лікар самостійно призначає пацієнту новий RV.
Архітектура сервісу видачі RV є такою:
 |
Лікарі стають ефективнішими, якщо їм більше не доводиться займатися RV. Якщо їх буде достатньо багато, їхній внесок у витрати на функціонування секретаріату буде незначним. Ми назвемо додаток [RdvMedecins]. Нижче наведено скріншоти, що ілюструють його роботу.
Головна сторінка програми виглядає так:
З цієї першої сторінки користувач (секретаріат, лікар) буде виконувати певну кількість дій. Ми наводимо їх нижче. Лівий знімок екрана показує вікно, з якого користувач надсилає запит, правий — відповідь, надіслану сервером.
 |
 |
 |
 |
 |
2.2. База даних
База даних, яку використовує додаток NHibernate, — це база даних MySQL5 із чотирма таблицями:
Вона слугуватиме нам орієнтиром для побудови всіх наших баз даних.
2.2.1. Таблиця [MEDECINS]
Вона містить інформацію про лікарів, які обслуговуються додатком [RdvMedecins].
 |  |
- ID: номер, що ідентифікує лікаря — первинний ключ таблиці
- VERSION: номер, що ідентифікує версію рядка в таблиці. Це число збільшується на 1 щоразу, коли до рядка вносяться зміни.
- NOM: прізвище лікаря
- PRENOM: його ім’я
- TITRE: його/її титул (пані, пані, пан)
2.2.2. Таблиця [CLIENTS]
Пацієнти різних лікарів заносяться до таблиці [CLIENTS]:
 |  |
- ID: номер, що ідентифікує клієнта — первинний ключ таблиці
- VERSION: номер, що ідентифікує версію рядка в таблиці. Це число збільшується на 1 кожного разу, коли до рядка вносяться зміни.
- NOM: ім’я клієнта
- PRENOM: його ім’я
- TITRE: титул (пані, пані, пан)
2.2.3. Таблиця [CRENEAUX]
У ній перелічено часові проміжки, у яких можливі RV:
 |
 |
- ID: номер, що ідентифікує часовий проміжок — первинний ключ таблиці
- VERSION: номер, що ідентифікує версію рядка в таблиці. Це число збільшується на 1 кожного разу, коли до рядка вносяться зміни.
- ID_MEDECIN: номер, що ідентифікує лікаря, якому належить цей часовий проміжок — зовнішній ключ у стовпці MEDECINS(ID).
- HDEBUT: час початку часового проміжку
- MDEBUT: хвилини початку часового проміжку
- HFIN: година закінчення часового проміжку
- MFIN: хвилини закінчення інтервалу
Другий рядок таблиці [CRENEAUX] (див. [1] вище) вказує, наприклад, що слот № 2 починається о 8:20 і закінчується о 8:40 та належить лікарю № 1 (пані Марі PELISSIER).
2.2.4. Таблиця [RV]
У ній наведено перелік RV, призначених кожному лікарю:
 |
- ID: номер, що однозначно ідентифікує RV — первинний ключ
- JOUR: день RV
- ID_CRENEAU: часовий проміжок запису RV — зовнішній ключ у стовпці [ID] таблиці [CRENEAUX] — визначає як часовий проміжок, так і відповідного лікаря.
- ID_CLIENT: номер клієнта, для якого зроблено бронювання — зовнішній ключ у стовпці [ID] таблиці [CLIENTS]
Ця таблиця має обмеження унікальності ( ) для значень з’єднаних стовпців (JOUR, ID_CRENEAU):
Якщо рядок таблиці [RV] має значення (JOUR1, ID_CRENEAU1) для стовпців (JOUR, ID_CRENEAU), це значення не може зустрічатися більше ніде. Інакше це означало б, що одночасно було зареєстровано два записи RV для одного й того самого лікаря. З точки зору програмування на Java драйвер JDBC бази даних запускає SQLException, коли трапляється такий випадок.
Рядок id, що дорівнює 7 (див. [1] вище), означає, що 10.09.2006 було заброньовано RV для слоту № 10 та клієнта № 2. З таблиці [CRENEAUX] ми дізнаємося, що слот № 10 відповідає часовому проміжку 11:00–11:20 і належить лікарю № 1 (пані Марі PELISSIER). З таблиці [CLIENTS] випливає, що клієнт № 2 — це пані Крістін GERMAN.
Цей приклад з практики став предметом статті Java [http://tahe.developpez.com/java/primefaces], у якій використовується ORM Hibernate для Java.