Створення бд і контексту даних

Створюємо базу даних

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

Отже, додамо в папку App_Data проекту базу даних. Назвемо її, наприклад, helpdeskuser.mdf

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

Створимо таблицю для моделі Category:

Далі створимо таблиці для моделей Department і Activ. Модель Department:

Модель Activ:

Так як модель Activ пов'язана через зовнішній ключ з моделлю Department, то при визначенні таблиці також прописуємо цей зовнішній ключ і вказуємо дію, яка буде відбуватися при видаленні пов'язаної моделі Department. У даному випадку поле DepartmentId прийматиме значення null.

Тепер додамо таблиці для ролей і користувачів. Таблиця для класу Role:

Також тут же можна і внести всі можливі ролі:

Визначення таблиці користувачів буде виглядати наступним чином:

Тут у нас вже два зовнішніх ключа. В принципі можна вже визначити одного користувача - адміністратора:

Цей адміністратор потім вже буде додавати всіх інших користувачів у додаток.

Тепер перейдемо до системи заявок. Спочатку додамо таблицю для сутності Lifecycle, яка описує життєвий цикл заявки. Скрипт створення таблиці буде виглядати наступним чином:

І скрипт створення таблиці заявок буде виглядати так:

 

GO

 

Тут у нас купа зовнішніх ключів і, крім того, ще не дуже зрозуміла конструкція наприкінці під назвою тригер, точніше два тригера. Загальна дія у нас така: у нас два поля - користувач, який створив заявку, і виконавець цієї заявки - посилаються на таблицю Users. Ми хочемо, щоб у разі видалення об'єкта з таблиці Users відповідні поля в таблиці Requests встановлювалися в NULL. Ну наприклад в реальності користувач відписався про якусь проблему, і раптом його звільнили (на рівні коду - видалили), але проблема могла залишитися, тому ми встановлюємо null. Однак ви також можете використовувати тут каскадне видалення (ON DELETE CASCADE)

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

По суті весь текст починаючи з GO і до слова END являє собою визначення тригера, який робить практично те ж саме, тільки для поля ExecutorId. У даному випадку використовується специфічне оголошення тригера.

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

Якщо в загальних словах, то створення тригера починається зі слів CREATE TRIGGER, після яких йде назва тригера. Далі вказуємо таблицю, за якою тригер буде стежити і операцію після слова AFTER, при проведенні якої тригер буде спрацьовувати. В обох випадках таблицею є Users. А ось операції у нас використовується дві: видалення для першого тригера, і оновлення для другого.

Сама дія проводить наступний код UPDATE Requests SET ExecutorId = NULL - звичайний вираз SQL, що встановлює значення NULL. А далі слідує умова, при якій відбувається таке присвоєння.

При видаленні умова WHERE Requests.ExecutorId IN (SELECT [Id] FROM [deleted]) говорить видалити ті рядки, де значення полів Requests.ExecutorId потрапляють в набір (SELECT [Id] FROM [deleted]). Слово deleted вказує на набір видалених об'єктів з таблиці Users.

При оновленні трохи більше складне рішення, бо нам треба перевірити, чи є оновлений об'єкт в таблиці Users по колишньому виконавцем.

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

Створення контексту даних

Отже, ми створили весь необхідний набір даних, який зараз виглядає таким чином:

Нас залишилося створити контекст даних, через який ми будемо отримувати всі необхідні відомості з бази даних. Так, додамо в папку Models клас HelpUserContext:

Тепер треба зв'язати контекст з базою даних. Відкриємо файл web.config змінимо в ньому стандартне визначення рядка підключення в секції connectionStrings на наступне:

<connectionStrings>

<add name="HelpUserContext" providerName="System.Data.SqlClient"

connectionString="Data Source=(LocalDb)\v11.0;AttachDBFilename=|DataDirectory|\helpdeskuser.mdf" />

</connectionStrings>

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