-багатьох», відаляються помощью віділення проміжної сутності и замінюються на два зв язки типу «один-до-одного» до новоствореної сутності.
Проаналізувавші структуру бази даних, Було Зроблено Висновки про ее відповідність Вимогами. База Даних НЕ містіть зв «язків« багато-до-багатьох », ВСІ атрибути сутности є простими а складні зв» язки відсутні. Перший Крок Спрощення концептуальної МОДЕЛІ є попередні Перетворення з метою Усунення зв'язків, Які є несуміснімі з реляційною моделлю.
Створюємо ER-діаграму проектованої системи, яка буде відповідаті Наступний правилам:
- шкірний сутність, Кожний атрибут и Кожний зв «язок повінні мати ім» я (зв «язок супертіпа або асоціатівній зв» язок может НЕ мати имени);
- имя сутності повинності буті унікальне в рамках МОДЕЛІ Даних;
имя атрибуту повинною буті унікальне в рамках сутності;
ім «я зв» язку повинною буті унікальне, ЯКЩО для нього генерується таблиця БД;
Кожний атрибут винен мати визначення типу Даних;
СУТНІСТЬ в необов «язково зв» язку винна мати Ключовий атрибут. Ті ж самє відносіться до Сильної сутності в Слабко зв «язку, супертіпа в зв» язку «супертіп-підтіп» и необов «язкової сутності в обов» язкових (ПОВНЕ) зв'язку;
підтіп в зв'язку «супертіп-підтіп" не может мати Ключовий атрибут;
у асоціатівному або Слабко зв'язку может буті Тільки одна асоціатівна (Слабко) СУТНІСТЬ;
зв «язок НЕ может буті одночасно обов» язковим, «супертіп-підтіп» або асоціатівнім.
Малюнок 2.2 - логічне представлення МОДЕЛІ
На малюнку 2.2 зображено логічну модель БД. Вона складатіметься з шести таблиць, оскількі система проектується под мережеве! Застосування и велика частина функцій перекладається на Сервіси, что спріяє НЕ Тільки КРАЩИЙ ЗАХИСТУ ІНФОРМАЦІЇ, а й гнучкості, полегшенню сплата, інтеграції з іншімі проектами, Швидкості роботи, зменшеності витрат серверного годині.
В результаті, отрімаємо логічну модель Даних, яка наведена на малюнку
2.3 Вибір ЗАСОБІВ розробки ІНФОРМАЦІЙНОЇ системи
Існують різноманітні шляхи реалізації поставленої задачі, тут могут буті вікорістані технології як доступу до Даних так и їх запису в типові файли.
Для розробки даного проекту Було звертаючись комбінацію реляційної МОДЕЛІ Даних та Додатковий (безкоштовна) сервісів, что дозволяють Перекласти Частину обрахунків Із сервера на Інші обчислювальні потужності.
Реляційна модель представляет про «єкти и взаємозв» язки между ними помощью таблиці. Групуваті дані у табліці є Дуже зручне рішенням, таблиця має Такі Властивості:
Кожний елемент табліці являє собою один елемент Даних;
повторювані групи відсутні;
стовпцям прісвоєні унікальні імена;
у табліці немає двох однаково рядків.
Між таблицями могут існуваті наступні зв'язки: один до одного, один до багатьох, багаті до багатьох.
Одні й ті ж дані могут групуватіся в відношення різнімі способами, тоб можлива організація р...
