тів групувань (категорія, місто, период подорожі, ТОЩО);
Виведення інформацію про шкірного туриста;
Виведення інформацію про рейси, Які обслуговують туристичну фірму;
визначення суми доходів агенції на Основі відомостей про ціни проживання у Готелі та вартості услуг (НАДАННЯ Представництвом), что візначає прибуток фірми:
визначення рентабельності фірми;
формирование звітів про клієнтську базу;
формирование фінансового Звіту на Основі відомостей про витрати та доходи агенції.
1.2 Визначення складу вхідніх та вихідних даних та способу їх организации
Для реализации даного проекту Було віділено 8 основних сутности. У якості ЗАСОБІВ забезпечення цілісності даних Використовують зазначені тіпі даних, певні бізнес-правила (у даного випадка обмеження на унікальність та обов`язковість, атрібутів).
Цілісність БД безпосередно забезпечують следующие обмеження:
. Розмір поля. Для даних типу Текстовий (string/char) вказується довжина рядка; для числових - тип числа (КОЖЕН тип має свой ДІАПАЗОН значень).
. маска поля. Удан проекті маска вікорістовується у полях, что мают тіпі ДАТА, ЧАС або Копійчаної.
. Унікальність та обов`язковість полів.
. Обмеження ТА значення.
. Неможливо Сменить значення первинного ключа головної табліці, если існує зв`язаній з ним запас Дочірньої табліці.
1.3 Вибір методів и ЗАСОБІВ проектування та создания бази даних
Розробка структури БД
Вдала розробка бази даних Забезпечує простоту ее ПІДТРИМКИ. Дані слід зберігаті в таблицях, причому Кожна таблиця винна містіті інформацію одного типу, например, Відомості про постачальніків. Тоді достаточно буде оновити конкретні дані, Такі як адреси, только в одному місці, щоб оновлена ??інформація відображалася у всій базі даних.
Одним з найбільш складних етапів у процессе проектування бази даних є розробка таблиць, тому что результати, Які винна відаваті база даних (звіти, вихідні форми ТОЩО). Не всегда дають ПОВНЕ уявлення про структуру табліці.
При проектуванні таблиць краще Розробити структуру на папері и только потім почінаті роботу з СУБД Access. При проектуванні таблиць, рекомендується Керувати такими основними принципами:
не винних бути повтореною между таблиці.
Колі Певна інформація зберігається только в одній табліці, то и змінюваті ее придется лишь в одному місці. Це Робить роботу ефектівнішою, а такоже віключає можлівість розбіжності информации в різніх таблицях. Например, в одній табліці мают містітіся адреси ї прізвіща КЛІЄНТІВ.
Кожна таблиця винна містіті інформацію лишь на одну тему.
Дані на шкірні тему опрацьовуються набагато легше, если містітіся смороду в незалежних один від Іншої таблицях. Например, адреси та замовлення КЛІЄНТІВ зберігаються в різніх таблицях, з тім, щоб при відаленні замовлення інформація про клієнта залиша в базі даних.
Кожна таблиця містіть інформацію на окрему тему, а Кожне поле в табліці містіть ОКРЕМІ дані по темі табліці. Например, у табліці з Даними про постачальніків могут буті поля з Назва компанії, адресою та номером телефону. При розробці полів для кожної табліці необходимо пам'ятати:
Кожне поле має буті пов'язане з темою табліці.
Чи не рекомендується включать до табліці дані, Які є результатом вирази.
У табліці має буті вся необхідна інформація.
Інформацію слід розбіваті на найменші логічні одиниці (например, поля Ім я и Прізвище raquo ;, а не загальне поле Ім я ).
Інфологічне проектування
Першів етапом и найголовнішім етапом у процессе проектування и создания бази даних, є розробка інфологічної моделі.
Мета інфологічного моделювання - забезпечення найбільш природних для людини способів збору и представлення тієї информации, якові передбачають зберігаті в створюваній базі даних. Основними конструктивними елементами інфологічніх моделей є сутності, зв'язки между ними та їх Властивості (атрибути).
Ключ - мінімальній набор атрібутів, за значеннями якіх можна однозначно найти необхідній екземпляр сутності. Мінімальність означає, что виключення з набору будь-которого атрибута не дозволяє ідентіфікуваті Сутність что залиша.
Зв язок - асоціювання двох або более сутности. Якби призначеня баз...
