1 Моделювання реляційної структури бази даних

1. Систематизація вимог до бази даних

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

1. Забезпечення масштабованості, внаслідок збільшення рівня продаж та звернень клієнтів.

2. Зменшення обсягів надмірної інформації.

3. Полегшення роботи, та зменшення її трудомісткості.

4. Забезпечення ефективного обліку необхідних даних.

5. Прискорення процесу обслуговування клієнтів.

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

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

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

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

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

2. Семантичне моделювання даних

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

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

Тому для забезпечення вимог моделювання ­ – створимо діаграму «сутність – зв’язок» (див. додаток А). Діаграма «сутність – зв’язок» є однією з ключових концепцій, які використовуються в процесі розробки бази даних. За допомогою цієї діаграми структура даних може бути чітко спроектована перед тим, як модель буде реалізована у вигляді бази даних. Діаграма «сутність – зв’язок» включає в себе логічні (віртуальні) об’єкти, які були використані для представлення в базі даних об’єктів реального світу, і взаємозв’язки між цими об’єктами. Для салону з продажу автомобілів виділимо такі сутності, на основі завдань, та вказаних там необхідних об’єктів:

• Людина

• Адреса

• Країна

• Співробітник

• Посада

• Клієнт

• Постачальник

• Автомобіль

• Статус автомобіля

• Модель

• Тип кузова

• Тип двигуна

• Операція продажу

• Спосіб оплати

Для сутності Людина виділимо такі атрибути: ідентифікатор, прізвище, ім’я, по батькові, дата народження та номер телефону.

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

Сутність адреса містить атрибути область, місто, вулиця, будинок, квартира та індекс. Вона пов’язана з сутностями людина, тип адреси та країна.

Сутність співробітник має атрибути дата прийому на роботу, та заробітна платня, іншу інформацію вона отримує завдяки зв’язкам з сутностями людина та посада.

Сутність клієнт власний атрибут лише контактна інформація, інші дані вона бере з зв’язку з сутностями людина.

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

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

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

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

Для перетворення діаграми «сутність – зв'язок» на реляційну систему, треба виконати наступну сукупність кроків:

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

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

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

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

Розглянемо структури таблиць, які утворилися внаслідок покрокового перетворення діаграми «сутність – зв'язок» на реляційну базу даних (табл. 1.1 – 1.14)

Таблиця 1.1 – Структура таблиці Людина

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	ЧеловекИдн	INT	NOT NULL	Первинний ключ
2	Фамилия	VARCHAR(50)	NOT NULL	­–
3	Имя	VARCHAR(50)	NOT NULL	–
4	Отчество	VARCHAR(50)	DEFAULT = ‘Не определено’	–
5	ДатаРождения	DATETIME	NOT NULL	–
6	НомерТелефона	PhoneNo	DEFAULT = ‘Не определено’	–

Таблиця 1.2 – Структура таблиці Страна

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	СтранаИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	­–

Таблиця 1.2 – Структура таблиці Тип Адреса

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	СтранаИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	­–

Таблиця 1.3 – Структура таблиці Адрес

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	ЧеловекИдн	INT	NOT NULL	Первинний ключ, Зовнішній Ключ
2	ТипАдресаИдн	INT	NOT NULL	­ Первинний ключ, Зовнішній Ключ
3	СтранаИдн	INT	NOT NULL	Первинний ключ, Зовнішній Ключ
4	Область	VARCHAR(50)	DEFAULT = ‘Не определено’	–
5	Город	VARCHAR(50)	NOT NULL	–
6	Улица	VARCHAR(50)	NOT NULL	–
7	Дом	NCHAR(10)	NOT NULL
8	Квартира	VARCHAR(20)	DEFAULT = ‘Не определено’
9	Индекс	VARCHAR(20)	DEFAULT = ‘Не определено’

Таблиця 1.4 – Структура таблиці Должность

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	ДолжностьИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	­–

Таблиця 1.5 – Структура таблиці Сотрудник

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	СотрудникИдн	INT	NOT NULL	Первинний ключ
2	ЧеловекИдн	INT	NOT NULL	­Зовнішній Ключ
3	ДолжностьИдн	INT	NOT NULL	­Зовнішній Ключ
4	ДатаПри’маНаРаботу	DATETIME	DEFAULT поточна дата	–
5	Зарплата	МОNEY	NOT NULL	–

Таблиця 1.6 – Структура таблиці Клиент

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	КлиентИдн	INT	NOT NULL	Первинний ключ
2	ЧеловекИдн	INT	NOT NULL	­Зовнішній Ключ
3	КонтактнаяИнформация	VARCHAR(50)	DEFAULT = ‘Не определено’	–

Таблиця 1.7 – Структура таблиці Поставщик

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	ПоставщикИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	–
3	НомерСчета	INT	NOT NULL	–
4	КонтактнаяИнформация	VARCHAR(50)	DEFAULT = ‘Не определено’	–

Таблиця 1.8 – Структура таблиці СпособОплаты

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	СпособОплатыИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	­–

Таблиця 1.9 – Структура таблиці СтатусАвтомобиля

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	СтатусАвтомобиляИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	­–

Таблиця 1.10 – Структура таблиці ТипКузова

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	ТипКузоваИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	­–

Таблиця 1.11 – Структура таблиці ТипДвиателя

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	ТипДвиателяИдн	INT	NOT NULL	Первинний ключ
2	Название	VARCHAR(50)	NOT NULL	­–

Таблиця 1.12 – Структура таблиці Модель

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	МодельИдн	INT	NOT NULL	Первинний ключ
2	ТипКузоваИдн	INT	NOT NULL	­ Зовнішній Ключ
3	ТипДвигателяИдн	INT	NOT NULL	Зовнішній Ключ
4	Марка	VARCHAR(50)	NOT NULL	–
5	Название	VARCHAR(50)	NOT NULL	–
6	Длинна	VARCHAR(50)	NOT NULL	–
7	Ширина	VARCHAR(50)	NOT NULL	–
8	Высота	VARCHAR(50)	NOT NULL	–
9	Вес	VARCHAR(50)	NOT NULL	–
10	ОбъёмДвигателя	VARCHAR(50)	NOT NULL	–
11	МощностьДвигателя	VARCHAR(50)	NOT NULL	–

Таблиця 1.13 – Структура таблиці Автомобиль

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	АвтомобильИдн	INT	NOT NULL	Первинний ключ
2	МодельИдн	INT	NOT NULL	­ Зовнішній Ключ
3	ПоставщикИдн	INT	NOT NULL	Зовнішній Ключ
4	СтатусАвтомобиляИдн	INT	NOT NULL	Зовнішній Ключ
5	НачальнаяЦена	MONEY	NOT NULL	–
6	Цвет	VARCHAR(50)	NOT NULL	–

Таблиця 1.14 – Структура таблиці Покупка

Номер атрибуту	Назва	Тип даних	Обмеження	Призначення
1	ПокупкаИдн	INT	NOT NULL	Первинний ключ,
2	КлиентИдн	INT	NOT NULL	Зовнішній Ключ
3	СотрудникИдн	INT	NOT NULL	Зовнішній Ключ
4	АвтомобильИдн	INT	NOT NULL	­ Зовнішній Ключ
5	СпособОплатыИдн	INT	NOT NULL	Зовнішній Ключ
6	ЦенаПокупки	VARCHAR(50)	NOT NULL	–
7	ДатаПокупки	VARCHAR(50)	DEFAULT поточна дата	–