Концептуальна модель бази даних розкладу рейсів автостанції

3. Логічне проектування.

Концептуальна модель, що описана попереднім малюнком, може бути перетвореною в реаляційну на підставі наступних простих принципів.

На першому єтапі виділяємосутності сильног типу (або сутності, що існують незалежно від інших і у зв‘язках приймають участь лише на боці одиниці ) і об'єктні множини – слабкого (або сутності, що не можуть існувати незалежно від інших).

Об'єктні множини сильного типу (або сутності, що існують незалежно від інших ) преобразовуются в таблиці з такими ж іменами і полями, відповідними атрибутам множини. В нашому випадку це множини „поставщики”, „клиенти” та „типы.”

Об'єктні множини – слабкого типу перетворяться в таблиці з такими ж іменами. Поля таблиць відповідають тільки тим атрибутам множини, які є характерними для конкретизації і не властиві узагальненню. Кожна множина отримує зовнішний ключ – посилання на первинний ключ головної таблиці. (Таблиці товари та закази)

Складові об'єктні множини – стають таблицею перетинів, і таблиці перескающихся множин поповнюються новими атрибутами – якщо немає атрибутів характерних саме для перетину (деталі виробу, операції - деталі).

Відношення перетворяться таким чином:

0. таблиці успадковують відносини відповідних об'єктних множин;

0. відношення один до одного звичайно перетвориться шляхом злиття двох таблиць в одну рядка, якого містять атрибути обох об'єктів;

0. для кожного відношення один до багатьох в таблицю об'єкту, для якого потужність відношення рівна “багато ” включається стовпець, що є зовнішнім ключем, вказуючим на інший об'єкт для якого потужність відношення рівна 1;

0. для створення відношення багато хто до багато кого створюється таблиця перетину.

0. рекурсивні відносини приводять до появи рекурсивних зовнішніх ключів, і може бути нових полів, якщо потрібна цілісність даних

Відповідно до цієі технології звязок між заказми та товарами змінюється таблицею перетину з необхідними атрибутами. Реляційна схема даних приймає вигляд.

Кожний звязок між таблицями відповідає необхідному правилу логічної цілісності, що базується на посиланнях. З метою спрощення

технології редагування даних застосовуються механізми підтримки логічної цілосності даних – каскадне оновлення та каскадне видалення.

З урахуванням цих механізмів логічна цілісність посилань забороняє поповнення підпорядкованих таблиць записами, що не посилаються на відповідні записи головних таблиць. Для пришвидшення реалізії механізмів цілісності, що базуються на посиланнях індексуємо зовнішні ключі.

4. Проектування запитів

Запит – Автобус

Наступний запис є записом з угрупуванням, що містить інформацію з двох таблиць. Цей запит є частиною результуючого запиту «Итоговый по реквизиту». Ці таблиці є зв’язаними на основі внутрішнього з’єдання (INNER JOIN). Результатом його роботи є перекресна таблиця. Заголовок строк таблиці містить інформацію:

Запит – Кількість автобусів

Він підраховує кількість автобусів на автостанції, які були направлені по розкладу.

Count([Номер_автобуса]).

Запит має такий вигляд:

Запит – Рейси

Цей запит потрібен для друку звіту «Рейсів автобусів». Повністю цей запит можна представити описаним на мові SQL:

SELECT Рейсы.Направление, [Тип автобуса].[Количество мест], [Тип автобуса].[Наименование модели]

FROM [Тип автобуса] INNER JOIN (Автобус INNER JOIN Рейсы ON Автобус.[Номер автобуса] = Рейсы.[Номер автобуса]) ON [Тип автобуса].Id_типа = Автобус.[Тип автобуса];

Також база має такі запити :

• Параметризований

• Перехресний

• Запит на додавання

• Запит на оновлення