="justify"> необходимо Установити, Які з атрібутів всегда повінні містіті Одне з Припустиме значення. Если Говорити більш конкретніше то це атрибути, что всегда повінні мати значення, відмінні від NULL.
например, атрибути Номер працівника и ПІБ сутності Працівник всегда винне містіті значення, відмінні від порожнього. Альо на атрибут Телефон цієї ж сутності дана Вимога НЕ пошірюється, и ЦІ атрибути Цілком могут мати значення NULL, Що означає что в клієнта або немає телефону, або номер его невідомий, або зазначену значення віявілося некоректно.
Докладні зведення про атрибути, что входять у локального модель даних були пріведені у табліці 1.3.
Обмеження для доменів атрібутів:
Домен атрибуту встановлює набор Припустиме значень, что могут прівласнюватіся Цьом атрібутові.
например, набор Припустиме значення для атрибуту Номер_працівніка сутності Працівник представляет собою всі Можливі рядки довжина від одного до п'яти сімволів.
Докладні зведення про домени атрібутів, что входять у локального модель даних були пріведені у табліці 1.4.
Цілісність сутности:
Атрибут первинного ключа сутності НЕ может мати значення NULL.
например, КОЖЕН екземпляр сутності Відділення обов'язково повинною мати конкретне значення атрибуту его первинного ключа Номер. Атрибут, что входять у значення первинного ключа кожної сутності, були візначені при віконанні етапів 2.5 и 3.2.
Посілальна цілісність:
Зв'язки между сутности моделюються помощью переміщення в ДОЧІРНЄ відношення копії первинного ключа батьківського відношення. Поняття посілальної цілісності означає, что если Зовнішній ключ Дочірнього відношення містіть деяке значення, то це значення повинності посілатіся на існуюче и коректний значення ключа в батьківському відношенні.
Підтримка посілальної цілісності організовується помощью Завдання необхідніх обмежень для значень Первін и ЗОВНІШНІХ ключів.
Варто вказаті умови для шкірного зовнішнього ключа, что повінні Виконувати при відновленні або відаленні відповідного значення первинного ключа. У цьом випадка можна застосуваті одну з запропонованіх стратегій - NO ACTION, CASCADE, SET NULL, SET DEFAULT або NO CHECK.
Вимоги даного підприємства
ЦІ вимоги, ще назівають бізнес-правилами, Які визначаються тимі методами ї ограниченной, что прійняті на підприємстві.
Одним з них є ті, что диспетчер не может редагуваті дані про проведені ремонти, а головний інженер - про здійснені перевезення.
Для реализации бізнес правил створімо представлення для двох Користувачів:
view «Dispatcher» («Transporting number», «Date», «Customer», «Payment type», «Cargo», «Route», «car number», «Car model», « Driver number »,« Driver Name »,« Driver Second Name »,« Car type »,« Cargo name »,« Cargo Size »,« Cargo type »,« measure »,« Rout length »,« Rate »,« driver town »,« driver street »,« driver building »,« driver room ») asc1. «TrNum», c1. «TrDate», c1. «TrCustomer», c1. «TrPaymentType», c1. «Cargo», c1. «Route», c1. «CarLicenseNum», c2. «CarModel», c1. «Driver», c3. «EmpFName», c3. «EmpSName», c2. «CarTipe», c4. «CrName», c4. «CrSize», c4. «CrTipe», c4. «Measure», c5. «RtLength», c5. «RtRate», c3. «EmpTown», c3. «EmpStreet», c3. «EmpBuilding», c3. «EmpRoom» «Transporting» c1, «Car» c2, «Employee» c3, «Cargo» c4, «Route» c5 with check option; view «Chief engineer» («Repair number», «Repair date», «Repaire description »,« Mechanic number »,« Name »,« Second name »,« date of birs »,« date of employment »,« Garage »,« car license number »,« car model" ,?? car type »,« car date of manufactures »,« car milage »,« car fuel per 100 km »,« driver ») asc1. «RpNum», c1. «RepDate», c1. «RepDescription», c1. «Mechanic», c2. «EmpFName», c2. «EmpSName», c2. «EmpDoB», c2. «EmpDateOfEmployment», c3. «MhGarageNum», c1. «CarLicenseNum», c4. «CarModel», c4. «CarTipe», c4. «CarDoM», c4. «CarMileage», c4. «CarFuelPer100km», c4. «Driver» «Repair» c1, «Employee» c2, «Mechanic» c3, «Car» c4 with check option;
3.6 Обговорення Розроблення логічніх моделей даних з кінцевімі Користувачами
На цьом етапі віконується Остаточна перевірка локальної логічної моделі даних, здійснювана помощью Обговорення ее з Користувачами. Основним об'єктом Обговорення для розроблювачів и Користувачів є ER-Діаграма. Однак не Менш Важлива, щоб Користувачі уважности ознайомитись Із супровідною документацією. Если в моделі або документації буде Знайду будь-яка невідповідність, усі необхідні етапи повінні ...
