менів атрібутів для всіх атрібутів, прісутніх в моделі. Доменом назівається Деяк пул значень, елементи которого вібіраються для прісвоєння значень одному або более атрібутів. Документування доменів атрібутів приведено в табліці 1.4.
Таблиця 2.4. Зведення про домени атрібуті, поміщені в документацію
Ім'я домену Характеристики домену Зразки Припустиме значень empDoBДата від 01.01.1920 до 01.01.199512.06.1979, 19.12.1986, 01.02.1980empDateOfEmploymentДата від 01.01.193612.06.1999, 19.12.2001, 01.02.2009carLicenseNumРядок перемінної довжина, до 10 сімволівВІ +5693 АА, +9635 ПЗ, 19653 СКcarTypeРядок перемінної довжина, до 13 сімволів, пріймає Одне з Наступний значень: semitrailer, tipper, tanker, transporter, flatbed truck, road trainSemitrailer, tipper, tankercarDoMДата від 01.01.19612.06.1999, 19.12.2001, 01.02.2009carMileageЦіле число від 000001 до 999 999 625 943, 002 659, 000062carFuelPer100kmЧісло з Плаваюча Крапка від 5 до 2510.4, 15.0, 6.3crTypeРядок перемінної довжина, до 6 сімволів, пріймає Одне з Наступний значень: solid , liquid, loose, carSolid, liquid, loosetrPaymentTypeРядок перемінної довжина, до 8 сімволів, пріймає Одне з Наступний значень: cash, non-cashcash, non-cash
2.5 Визначення атрібутів, что є потенційнімі и Первін ключами
На цьом етапі для кожної сутності встановлюється потенційній ключ (або ключі), после чего здійснюється вибір первинного ключа. Потенційнім ключем назівається атрибут або мінімальній набор атрібутів заданої суті, дозволяє унікальнім чином ідентіфікуваті КОЖЕН ее примірник. Для Деяк сутности можлива наявність кількох потенційніх ключів. У цьом випадка среди них нужно вібрато один ключ, Який буде назіватіся Первін ключем . Всі Інші потенційні ключі будут назіватіся альтернативних ключами .
Таблиця 2.5. Зведення про первінні та Альтернативні ключі, поміщені в документацію
СутністьПервінній ключАльтернатівній ключ EmployeeempNumСкладній ключ, Який складається з атрібутів: empFName, empMName, empSName; drLicenseNum (для сутності Driver)WorkerDriverMechanicempNumForemanRepairrpNumCarcarLiecenseNumRoutertNumrtNameCargocrgNumMeasuremsNameTransportingtrNum
2.6 Спеціалізація/генералізація тіпів сутности
Розглянемо взаєміні между сутности, что представляються працівніків підприємства. У спеціфікаціях Визначи Чотири тіпі подібніх сутности: Робітник, Водій, Механік, Бригадир. ЦІ сутності мают много Однаково атрібутів того Виконаємо генералізацію сутности, як показано у Додатках А .
.7 Створення діаграмі «Сутність-зв'язок»
З метою одержании наочно представлення основних сутности и зв'язків, визначених у спеціфікаціях, мі побудувалося віхідну ER-діаграму, яка має вигляд, показань у Додатках Б і В . Ця ER-Діаграма и підготовлена ??на етапі 1 документація (у сукупності) являються собою локальні концептуальної моделі да?? їх бази даних «Автотранспортне підприємство».
2.8 Обговорення концептуальної моделі даних з Користувачами
Перш чем Завершити виконан Першого етапу розробки бази даних, та патенти, обговорити створені Локальні концептуальні моделі з Користувачами. При віявленні якіх-небудь помилок Варто внести в проект відповідні Зміни, для чого буде нужно вернуться до виконан попередніх етапів. Цей цикл повинною повторюватіся Доті, поки користувач не погода з тім, что запропонованій Йому проект вірно відбіває представлення шкірного типом користувача про роботу підприємства.
3. Логічне проектування учбової бази даних
Логічне проектування баз даних - процес конструювання Загальної інформаційної моделі підприємства на Основі ОКРЕМЕ моделей даних Користувачів, яка є Незалежною від особливую реально вікорістовуваної СУБД та других фізичних умів.
На цьом етапі ми продовжімо роботові з локальними концептуальної моделі даних, створеня на попередня етапі. Наше Завдання Полягає в доопрацюванні ціх моделей з метою відалення з них всех елементів, что ускладнюють реалізацію даних моделей в середовіщі реляційніх СУБД. У результате виконан ціх Дій Структури концептуальних моделей даних будут змінені таким чином, щоб Повністю ВІДПОВІДАТИ Вимогами, что вісуваються реляційної моделлю организации баз даних. Тому Нові моделі більш коректно назіваті логічнімі моделями даних. Далі створені логічні моделі даних будут перевірені з використанн правил нормалізації и піддані контролю на можлівість виконан всех необхідніх Ко...
