ристувачами транзакцій так, як це зазначилися у спеціфікаціях на створюваній приложение. Згідно перевірені логічні моделі даних можна буде використовуват як прототип, если це буде нужно.
У результате виконан даного етапу будут створені коректні, повні та точні моделі уявлень Користувачів. Це дасть нам міцну основу, необхідну для виконан следующего етап, что Полягає в об'єднанні ОКРЕМЕ локальних логічніх моделей даних в єдину глобальної моделі даних Всього підприємства.
3.1 Перетворення концептуальної моделі Даних у логічну модель
На цьом етапі ми займемося перетворенням концептуальної моделі даних з метою відалення з неї всех структур, реалізація якіх у СУБД реляційного типу скрутна. Бажанов результат может буті досягнуть помощью виконан таких Дій, як:
1. Відалення зв'язків типом M: N.
2. Відалення складних зв'язків.
. Відалення рекурсивних зв'язків.
. Відалення зв'язків, что мают атрибути.
. Відалення множини атрібутів.
. Повторні огляд зв'язків типом 1: 1.
. Відалення надлишково зв'язків.
Відалення зв'язків типом много до багатьох
У локальній концептуальній моделі даних зв язки типу Б: Б відсутні, тому ми Переходимо до следующего етапу.
Відалення складних зв'язків
На цьом етапі проводитися відалення будь-якіх складення (НЕ бінарніх) зв язків, что є прісутнімі у концептуальній моделі. У локальній концептуальній моделі даних для програми «Автотранспортне підприємство» складні зв язки відсутні, тому ми Переходимо до следующего етапу.
Відалення рекурсивних зв'язків
У локальній концептуальній моделі даних рекурсівні зв'язки відсутні, тому ми просто Переходимо до следующего етапу.
Відалення зв'язків, что мают атрибути
Прісутність зв'язків з атрибутами может вказуваті на наявність у моделі щє не віділеніх сутности. У нашому випадка таких атрібутів немає.
Відалення множини атрібутів
У локальній концептуальній моделі даних множінні атрибути відсутні, тому ми Переходимо до следующего етапу.
повторно огляд зв'язків типом 1: 1
У Деяк випадка сутності, что беруть доля у зв язку 1: 1, могут Фактично представляті Різні аспекти того самого про єкту. З цієї причини рекомендується знову проаналізуваті Зміст усіх зв язків типом 1: 1, что є прісутнім у моделі даних. У локальній концептуальній моделі, розробленій во время виконан курсової роботи Такі зв язки наявні: бригадир Керує бригадою и водій працює на автомобілі , однак зовсім очевидно, что сутності, что беруть доля у ньом, представляються Різні про єкти реального світу.
Відалення надлишково зв'язків
У локальній концептуальній моделі даних надлішкові зв язки відсутні, тому ми Переходимо до следующего етапу.
Створення діаграм «Сутність-зв язок»
ORM-Діаграма, что представляет локальних концептуальної моделі даних для програми «Автотранспортне підприємство» , булу показана в Додатках 1. При віконанні Етап 2.1 ця модель не змінілася.
Если відбуліся Зміни очень Важлива такоже внести всі необхідні Зміни в прікладену до логічної моделі даних документацію. ЦІ Зміни повінні відбіваті результати модіфікації моделі, віконаної на даного етапі.
3.2 Визначення набору відношень віходячі зі Структури логічної моделі даних
На цьом етапі нашою задачею буде создания відношень, что представляються сутності и зв'язки, локальної логічної моделі даних програми «Автотранспортне підприємство» . ( дів. Додаток Г ).
Зв'язки между сутности моделюються помощью механізму Первін и ЗОВНІШНІХ ключів. Для Опису складу всех створюваніх відношень буде використовуват мова DDL.
table `Team` (
`TmName` CHAR (15),
`TmSpecialization` CHAR (15),
`Foreman` CHAR (10), constraint` Team_PK` primary key (`Foreman`,` TmName`)); table `Transporting` (
`trNum` CHAR (10),
`TrDate` DATETIME,
`TrCustomer` CHAR (25),
`TrPaymentType` CHAR (13),
`Route` CHAR (25),
