На сайті 11893 реферати!

Усе доступно безкоштовно, тому ми не платимо винагороди за додавання.
Авторські права на реферати належать їх авторам.

Проектування бази даних предметної області „Онлайн-магазин”

Реферати > Комп'ютерні науки > Проектування бази даних предметної області „Онлайн-магазин”

Продовження таблиці 2.1

Назва атрибуту

Опис

Пок_стать

Стать покупця

Пок_вік

Вік покупця

Пок_адреса

Адреса покупця

Пок_E-mail

E-mail покупця

Пок_телефон

Номер телефону покупця

З_код

Порядковий номер замовлення

З_код_покупця

Код покупця, що зробив замовлення

З_тип_товару

Вид замовленого товару

З_код_товару

Код товару, що замовлено

З_кількість

Кількість одиниць замовленого товару

З_дата

Дата замовлення

З_доставка

Вид доставки

Ступінь універсального відношення становить 72.

3 РОЗРОБКА КОНЦЕПТУАЛЬНОЇ СХЕМИ ПРЕДМЕТНОЇ ОБЛАСТІ «ОНЛАЙН-МАГАЗИН» за ER-принципом

З метою опису предметної області “Онлайн-магазин” складемо концептуальну схему. Дана схема відбиватиме основні категорії предметної області у їх взаємозв’язках. Для цього використаємо принцип Entity-Relation, обравши як варіант подання ER-модель.

Розглянувши сформовані запити, відзначимо сутності та зв’язки між ними.

В якості сутностей для предметної області “Онлайн-магазин” виберемо наступні об’єкти: “Комп’ютер”, “Комплектуюче”, “Периферія”, “Диск”, “Аксесуар”, “Мережеве обладнання”, “Покупець”, “Замовлення”.

Розглянемо зв’язки між зазначеними сутностями.

Між сутностями “Покупець” та “Замовлення” – зв’язок багато-до-багатьох, оскільки покупців багато і вони можуть робити однакові замовлення.

Між сутністю “Замовлення” та сутностями, що представляють різні типи товару (“Комп’ютер”, “Комплектуюче”, “Периферія”, “Мережеве обладнання”, “Аксесуар”, “Диск”), існують зв’язки багато-до-багатьох, так як кожне замовлення може містити одну одиницю або більше одиниць товару, а один і той самий товар може бути присутнім в одному або більше замовленнях.

На рис. 3.1 зображено ER-модель предметної області “Онлайн-магазин”.

Рисунок 3.1 – ER-модель предметної області “Онлайн-магазин”

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

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

Більш широкі можливості для користувача забезпечує мережна модель бази даних, яка є узагальненням ієрархічної моделі і дозволяє відображати відношення між типами записів виду багато-до-багатьох [1].

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

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

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

4 ПРОЕКТУВАННЯ НОРМАЛІЗОВАНИХ ВІДНОШЕНЬ

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

Зазвичай виділяють п’ять нормальних форм. Розглянемо перші три щодо відношень предметної області “Онлайн-магазин”.

Проаналізуємо отримане універсальне відношення:

R (К_код, К_модель, К_категорія, К_ОП, К_частота, К_hdd, К_відеопам’ять, К_виробник, К_вартість, К_опт, К_ціна_закупівлі, К_кількість, К_дата_надходження, Ком_код, Ком_модель, Ком_категорія, Ком_виробник, Ком_вартість, Ком_опт, Ком_ціна_закупівлі, Ком_кількість, Ком_дата_надходження, П_код, П_модель, П_категорія, П_виробник, П_вартість, П_опт, П_ціна_закупівлі, П_кількість, П_дата_надходження, Д_код, Д_модель, Д_категорія, Д_виробник, Д_вартість, Д_опт, Д_ціна_закупівлі, Д_кількість, Д_дата_надходження, А_код, А_модель, А_категорія, А_виробник, А_вартість, А_опт, А_ціна_закупівлі, А_кількість, А_дата_надходження, М_код, М_модель, М_категорія, М_виробник, М_вартість, М_опт, М_ціна_закупівлі, М_кількість, М_дата_надходження, Пок_код, Пок_ПІП, Пок_стать, Пок_вік, Пок_адреса, Пок_E-mail, Пок_телефон, З_код, З_код_покупця, З_тип_товару, З_код_товару, З_кількість, З_дата, З_доставка).

Перша нормальна форма (1NF) передбачає, що кожен атрибут таблиці атомарний і всі записи різні [2]. Ця умова для відношень даної предметної області виконується, оскільки поля-списки відсутні, записи не повторюються, тому що було введено поле коду у кожне з відношень і кожен запис містить унікальне значення з поля коду.

Друга нормальна форма (2NF) вимагає, щоб таблиця знаходилася в першій нормальній формі, і при цьому кожен її атрибут, що не входить до складу первинного ключа, функціонально повно залежав від первинного ключа. Функціонально повна залежність означає, що атрибут функціонально залежить від всього первинного ключа, але при цьому не знаходиться в функціональній залежності від будь-якої його частини [2]. Розглянемо існуючі функціональні залежності відношень:

Ф1. (К_код) → К_модель, К_категорія, К_ОП, К_частота, К_hdd, К_відеопам’ять, К_виробник, К_вартість, К_опт, К_ціна_закупівлі, К_кількість, К_дата_надходження.

Ф2. (Ком_код) → Ком_модель, Ком_категорія, Ком_виробник, Ком_вартість, Ком_опт, Ком_ціна_закупівлі, Ком_кількість, Ком_дата_надходження.

Ф3. (П_код) → П_модель, П_категорія, П_виробник, П_вартість, П_опт, П_ціна_закупівлі, П_кількість, П_дата_надходження.

Ф4. (Д_код) → Д_модель, Д_категорія, Д_виробник, Д_вартість, Д_опт, Д_ціна_закупівлі, Д_кількість, Д_дата_надходження

Перейти на сторінку номер: 1  2  3  4  5  6 Версія для друкуВерсія для друку   Завантажити рефератЗавантажити реферат