Администрирование, базы данных

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

Мета – полегшити і зробити більш ефективним управління послугами компанії.

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

Другим етапом створення  ефективної структури бази даних  є визначення обсягів (об’єм інформації впливає на розмір бази даних) і типів даних (факторів, що визначають обмеження, що накладаються на структуру даних), від яких безпосередньо залежить продуктивність бази даних.

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

• прізвище, ім’я, по батькові;
• посада та рівень заробітної плати працівника;
• головні посади управління компанії;
• перелік типів виробів, та заказів;
• строк та стадія заказу;
• ціни на проекти.

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

Наступним етапом створення  ефективної структури бази даних  є визначення способів використання бази даних, тобто виявлення тих, хто буде звертатися до даних і  характер задач, які він виконуватиме з ними.

У проектованій базі даних буде два види користувачів, а саме:

• управління компанії;
• працівники, що працює з клієнтами та проектами.

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

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

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

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

 

1.2 Розробка логічної та фізичної моделі даних

 

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

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

Основною ідеєю семантичних мереж є так звана тріада: суб’єкт – відношення – об’єкт.

Можна виділити наступні об’єкти реального світу, які представляють інтерес для проектування даної бази даних:

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

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

 Для проектування бази даних компанії виділяються наступні сутності:

• «Dolgnosti»;
• «Klient»;
• «Komitet»;
• «Magazin»;
• «Otdelu»;
• «Prodykziya»;
• «Proektu»;
• «Sotrydniki»;
• «Zar_plata»;
• «Zentr_obrabotki».

Сутності також характеризуються ще й зв’язками між собою. Відношення між сутностями – це віртуальний зв'язок, як правило, заснований на взаємовідносинах об’єктів реального світу. Відношення приймають одну із трьох форм, які називають кардинальністю, а саме: «один до одного», «один до багатьох», «багато до багатьох».

Тепер можна переходити до побудови моделі «ER-діаграми». «ER-діаграма» включає в себе фізичні об’єкти, які були використані для представлення в базі даних об’єктів реального світу, і взаємозв’язки між цими об’єктами. У випадку проектування бази даних для компанії діаграма визначає взаємовідносини.

 

Рисунок 1.1 - Модель «ER-діаграми»

Після створення моделі її можна  поступово перетворити в реляційну  базу даних. Для цього треба виконати наступну сукупність кроків:

− для кожної сутності створити базову таблицю, причому кожному атрибуту відповідає стовпчик таблиці. Ключовий атрибут стає первинним ключем таблиці, тобто тим елементом, який унікально визначає всі кортежі (рядки) таблиці;

− коли дві сутності беруть участь у зв’язку кардинальністю «один  до багатьох», то таблиця, яка визначається кардинальністю «багато», має містити  атрибут, який відповідає первинному ключу таблиці, яка відображає сутність кардинальністю «один». Цей атрибут називається зовнішнім ключем, який відображає сам зв'язок;

− коли дві сутності беруть участь у зв’язку кардинальністю «один  до одного», то в таблицю однієї із сутностей необхідно включити атрибут зовнішнього ключа, але не варто включати атрибут зовнішнього ключа в обидві таблиці задля запобігання невідповідності даних;

− якщо дві сутності беруть участь у відношенні кардинальністю «багато  до багатьох», то необхідно створити нову таблицю, яка складається з атрибутів, що є первинними ключами перших двох таблиць;

− якщо сутність має багатомірний атрибут, треба створити додаткову  таблицю, причому один із атрибутів  даної таблиці буде зовнішнім  ключем по відношенню до таблиці, що представляє сутність, а другий буде представляти багатозначний атрибут;

− якщо у зв’язку беруть участь більше двох сутностей, необхідно створити додаткову таблицю, яка складатиметься із атрибутів первинних ключів усіх таблиць, які представляють сутності – учасники;

− провести нормалізацію таблиць.

Розглянемо структури  таблиць, які утворилися внаслідок  покрокового перетворення «ER-діаграми» на базу даних. Загальна кількість таблиць у базі даних компанії – 10.

Структура таблиці «Dolgnosti», яка містить інформацію про особистий ID працівника, зв’язок «один до багатьох» та атрибут для первинного ключа , наведено в таблиці 1.1.

 

Таблиця 1.1 – Структура  таблиці «Dolgnosti»

Номер атрибуту	Назва атрибуту	Тип даних	Обмеження		Призначення атрибуту
			Пусте значення	Значення за замовчуванням
1	ID_dolg	int	NOT NULL	-	первинний ключ
2	Li4nuy_ID_sotrydnika	int	NOT NULL	-	код ідентифікації
3	ID_otdel2	int	NOT NULL	-	зовнішній ключ
4	ID_kom2	int	NOT NULL	-	зовнішній ключ

 

Таблиця «Klient» містить номер заказу, зв’язок «один до одного» та атрибут для первинного ключа. Структурне представлення таблиці наведене в таблиці 1.2.

 

Таблиця 1.2 – Структура  таблиці «Klient»

Номер атрибуту	Назва атрибуту	Тип даних	Обмеження		Призначення атрибуту
			Пусте значення	Значення за замовчуванням
1	ID_kl	int	NOT NULL	-	первинний ключ
2	Zakaz	int	NOT NULL	-	номер заявки
3	ID_mag	int	NOT NULL	-	зовнішній ключ

 

Структурне представлення таблиці «Komitet», де відображено керівництво компанії та атрибут для первинного ключа, знаходиться в таблиці 1.3.

 

 

 

 

Таблиця 1.3 – Структура  таблиці «Komitet»

Номер атрибуту	Назва атрибуту	Тип даних	Обмеження		Призначення атрибуту
			Пусте значення	Значення за замовчуванням
1	ID_komitet	int	NOT NULL	-	первинний ключ
2	Glova	varchar(25)	NOT NULL	-	керівництво

 

За допомогою даних, збережених у таблиці «Magazin», ведеться облік проектів прийнятих під заказ для продажу та атрибут для первинного ключа. Структура даної таблиці наведена в таблиці 1.4.

 

Таблиця 1.4 – Структура  таблиці «Magazin»

Номер атрибуту	Назва атрибуту	Тип даних	Обмеження		Призначення атрибуту
			Пусте значення	Значення за замовчуванням
1	ID_magazin	int	NOT NULL	-	первинний ключ
2	Prodykziya	varchar(30)	NOT NULL	-	назва ПЗ

 

Базова таблиця «Otdelu» призначена для зберігання загальної інформації про назву відділення та профіль діяльності. Має зв’язок «один до одного» та атрибут для первинного ключа , структура наведена в таблиці 1.5.

 

Таблиця 1.5 – Структура  таблиці «Otdelu»

Номер атрибуту	Назва атрибуту	Тип даних	Обмеження		Призначення атрибуту
			Пусте значення	Значення за замовчуван.
1	ID_otd	Int	NOT NULL	-	первинний ключ
2	Nazvanie	varchar(25)	NOT NULL	-	назва відділення
3	Bid_deyatelbnosti	varchar(50)	NULL	-	профіль діяльності
4	ID_kom1	int	NOT NULL	-	зовнішній ключ