Розробити інформаційно-керуючу систему для аукціонного дому

Завдяки всім вище перерахованим перевагам були обранi саме цi засoби реалізації програмного продукту.

 

 

 

2.2 Високорівнева концептуальна модель «Сутність – зв'язок» або ER-модель

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

ER-модель (Entity Relationship model) або модель «Сутність – зв’язок» – це високорівнева концептуальна модель даних, яка була розроблена Ченом (Chen) в 1976 р. з метою спрощування задач проектування баз даних. Ця модель даних уявляє собою набір концепцій, які описують структуру бази даних та пов’язані з нею транзакції оновлення та вилучення даних.

Головними поняттями моделі «Сутність - зв’язок» вважаються сутності, атрибути та зв’язки.

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

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

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

Під екземпляром сутності розуміється конкретний об’єкт.

На ER-діаграмі сутність зображується прямокутником, в якому вказане її ім’я.

Сутності мають властивості, які називаються атрибутами. Атрибути повинні дозволяти розрізняти екземпляри сутності. На ER-діаграмі атрибути зображуються овалами, в яких вказуються їх імена. Атрибути поєднуються з сутностями прямими лініями.

Атрибуты, які однозначно ідентифікують сутність, називаються ключовими атрибутами. Ключові атрибути на ER-діаграмі підкреслюються.

В деяких ситуаціях з декількох простих атрибутів може бути сформований складений.

За допомогою зв’язків на ER-діаграмі відображається взаємодія між сутностями. Зв’язок зображується ромбом, який поєднує сутності. Всередині ромбу вказується вид зв’язка. Кількість сутностей, які приймають участь в зв’язку, визначає її ступінь.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.3 Структурна схема реляційної  бази даних та

описання таблиць  бази даних

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

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

Реляційні системи беруть початок в математичній теорії множин. Вони були запропоновані наприкінці 1968 р. доктором  Е. Ф. Коддом з фірми IBM. В термінології реляційної моделі даних кожен стовпець таблиці називається полем (атрибутом), а кожен рядок таблиці – записом (кортежем).

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

Дані в одному полі можуть мати значення лише з деякої сукупності припустимих значень, яка  називається доменом.

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

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

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

Відношення лише з  одним атрибутом має ступінь 1 та називається унарним відношенням. Відношення з двома атрибутами має назву бінарне, відношення з трьома атрибутами – тернарне, а для відношень з більшою кількістю атрибутів використовується термін n-парний.

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

Для предметної області «Розробити інформаційну систему для автоматизації роботи аукціону» була побудована реляційна модель, зображена на рис. 2.2: Рис. 2.2 Структурна схема реляційної БД для предметної області

«Розробити інформаційну систему для автоматизації роботи аукціону»

Зв'язок «один до одного»(1:1) означає: кожному значенню пов’язуючого поля відповідає один запис по обидва боки.

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

Окрім описаних вище зв'язків  в реляційній моделі даних підтримується  ще зв'язок «багато до багатьох», який означає: (М:N) – значення в полях неодноразово зустрічаються в пов’язаних відношеннях. Такий тип зв’язку треба обходити та розподіляти його на зв’язки 1:N (створюється третє відношення, яке пов’язується з початковими зв’язками 1:N). 

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

Нормалізація відношень забезпечує ефективність структур даних в реляційній БД. Цей процес зменшує надмірність даних (зберігання однакових даних в декількох місцях). В результаті більш раціонально використовується зовнішня пам’ять, зменшується ймовірність порушення узгоджуваності даних.

Нормалізація являє  собою дії послідовного перетворення початкової (ненормалізованої) таблиці в нормализовані відношення в першій нормальній формі (1НФ), 2НФ, 3НФ, нормальній формі Бойса-Кодда (НФБК), 4НФ, 5НФ.

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

В базі даних кожна  таблиці зберігає окрему інформацію. База даних для АТС складється з 11 таблиць. БД містить наступні таблиці: «Аукціонна компанія», «Аукціон», «Автори», «Аукціоніст», «Клієнт(Продавець)», «Категорії», «Історія лота», «Лоти», «Послуги», «Склад лота», «Учасник покупець».

Розглянемо кожну таблицю  БД більш детально.

Рис 2.3(а) – Таблиця «Аукціонна компанія»

 

Назва поля	Опис
Код аукціонної компанії	Порядковий номер аукціонної компанії
Назва	Назва аукціонної компанії
тип	Тип компанії
Рік створення	Дата створення компанії
Розташування	Місце знаходження компаніі
Галузь	Галузь діяльності
Сайт	Сайт компанії

Рис 2.3(б) –  Опис полів таблиці  «Аукціонна компанія»

 

Рис 2.4(а) – Таблиця «Аукціон»

 

Назва поля	Опис
Код аукціону	Порядковий номер аукціону
Код аукціонної компанії	Порядковий номер аукціонної компанії
Назва аукціону	Назва аукціону
Місце проведення	Місце проведення аукціону
Тема аукціону	Тема аукціону
Дата початку	Дата початку аукціону
Дата завершення	Дата завершення аукціону

Рис 2.4(б) – Опис полів таблиці «Аукціон»

Рис 2.5(а) – Таблиця «Автори»

 

Назва поля	Опис
Код автора	Порядковий номер автора
Компанія	Назва Компанії-автора
ПІБ	Прізвище Імя По-Батькові Людини-автора
Напрям	Напрям за яким автор створив  лот

Рис 2.5(б) – Опис полів таблиці  «Автори»

 

Рис 2.6(а) – Таблиця «Аукціоніст»

 

Назва поля	Опис
Код аукціоніста	Порядковий номер аукціоніста
ПІБ	Прізвище Імя По-Батькові аукціоніста

Рис 2.6(б) – Опис полів таблиці  «Аукціоніст»

 

Рис 2.7(а) – Таблиця «Історія лота»

Назва поля	Опис
Код історії	Порядковий номер історії лота
Автор	Автор лота
Дата створення	Дата створення лота

Рис 2.7(б) – Опис полів таблиці  «Історія лота»

 

Рис 2.8(а) – Таблиця «Категорії»

 

Назва поля	Опис
Код категорії	Порядковий номер категорії
Категорії	Категорія, за якою визначається лот

Рис 2.8(б) – Опис полів таблиці  «Категорії»

 

Рис 2.9(а) – Таблиця «Клієнт(Продавець)»

 

Назва поля	Опис
Код продавця	Порядковий номер продавця
Код договору	Порядковий номер договору
ПІБ	Прізвище Імя По-Батькові продавця
Організація	Назва організації-продавця

Рис 2.9(б) – Опис полів таблиці  «Клієнт(Продавець)»

Рис 2.10(а) – Таблиця «Лоти»

Назва поля	Опис
Код лота	Порядковий номер лота
Назва	Назва лота
Продавець	Продавець лота
Аукціоніст	Аукціоніст, що реалізує лот
Код аукціону	Порядковий номер аукціону
Категорія	Категорія, що визначає лот
Початкова вартість	Початкова вартість лоту
Кінцева вартість	Кінцева вартість лоту
Шаг ставки	Мінімальна сума, яку потрібно внести зверху поточної вартості
Склад	Кількість екземплярів лота
Історія	Історія лота

Рис 2.10(б) – Опис полів таблиці  «Лоти»

 

Рис 2.11(а) – Таблиця «Послуги»

Назва поля	Опис
Код договору	Порядковий номер договору
Вид послуги	Вид послуги, що надається

Рис 2.11(б) – Опис полів таблиці  «Послуги»

Рис 2.12(а) – Таблиця «Склад лота»

Назва поля	Опис
Код лота	Порядковий номер лота
Кількість	Кількість екземплярів лота

Рис 2.12(б) – Опис полів таблиці  «Склад лота»

Рис 2.13(а) – Таблиця «Учасник(Покупець)»

Назва поля	Опис
Код покупця	Порядковий номер покупця
Імя	Імя покупця
Прізвище	Прізвище покупця
Дата народження	Дата народження покупця
Місце проживання	Місце проживання покупця
Кредитоспроможність	Інформація про фінансову могутність
Дата реєстрації	Дата реєстрації в аукціоні
Спосіб участі	Спосіб участі в аукціоні

 

Рис 2.13(б) – Опис полів таблиці  «Учасник(Покупець)»