ви. Так, в 1995 році був прийнятий стандарт SQL/CLI (Call Level Interface, інтерфейс рівня викликів), згодом перейменований в CLI95. На наступний рік був прийнятий стандарт SQL/PSM (Persistent Stored Modules, постійно збережені модулі), що отримав назву PSM - 96.
2. Розробка і реалізація проекту бази даних
.1 Інфологіческое моделювання системи
Інформаційно логічна схема БД «ГТС» (Малюнок 1).
У загальному випадку відповідно до процес проектування бази даних складається з трьох етапів:
концептуальне проектування
логічне проектування
фізичне проектування.
Концептуальне проектування бази даних. Призначенням 1 етапу є розробка концептуальної моделі предметної області, що базується на аналізі інформаційних потреб користувачів проектованої системи. Ця модель є об'єднання уявлень окремих користувачів розроблюваної бази даних.
Логічне проектування бази даних. На цьому етапі здійснюється вибір відповідної СУБД, а модель предметної області повинна бути представлена ??в термінах моделі даних концептуального рівня обраної конкретної СУБД (файли, сегменти, типи записів, реляційні таблиці).
Фізичне проектування бази даних. На даному етапі проводиться вибір бажаного способу організації бази даних у середовищі зберігання обраної СУБД і методів доступу до даних, використовуючи методи і засоби, що надаються проектувальнику системою управління базою даних.
Зовнішні моделі. Інформаційні потреби користувачів відображають зовнішні моделі. Ці моделі утворюють подання відповідних користувачів (завдань) про базу даних. Кожна зовнішня модель є деяким підмножиною бази даних. Такі підмножини можуть перетинатися, тобто частина даних різних моделей може бути однаковою.
При проектуванні бази даних можуть використовуватися два підходи. При першому підході спочатку встановлюються основні завдання, для вирішення яких будується база, і потреби завдань у даних. Строго відповідно до потреб виявляються інформаційні об'єкти, з яких повинна складатися БД. При другому підході вивчається предметна область, проводиться аналіз її даних і встановлюються типові об'єкти предметної області. Можливо поєднання обох підходів.
Рисунок 1 - Використання виробничих потужностей (у%)
2.2 Визначення логічної структури реляційної бази даних
Таблиця 2 - Логічна структура таблиці «Клієнти»
ДокументНаіменованіе реквізітаОбозначеніе реквізітаФункціональние залежності Клієнти Код абонента Прізвище Ім'я По батькові Стать Вік Номер телефону Тип телефонаКод_аб Прізвище Ім'я По батькові Стать Вік №телефона Тіп_телефонаСчетчік ключ
Таблиця 3 - Логічна структура таблиці «Абоненти»
ДокументНаіменованіе реквізітаОбозначеніе реквізітаФункціональние залежності Абоненти Номер телефону Пільги Міжмісто Оплата Розмір оплати Код АТС№телефона Пільги Міжмісто Оплата Размер_оплати Код_АТССоставной ключ
Таблиця 4 - Логічна структура таблиці «АТС»
ДокументНаіменованіе реквізітаОбозначеніе реквізітаФункціональние залежності АТС Код АТС Тип АТС Адреса АТСКод_АТС Тип АдресСчетчік ключ
Таблиця 5 - Логічна структура таблиці «Установка»
ДокументНаіменованіе реквізітаОбозначеніе реквізітаФункціональние залежності Установка Код абонента Черга Технічна можливість Код АТСКод_аб Черга Тех_возм Код_АТССчетчік ключ
Таблиця 6 - Логічна структура таблиці «Таксофони»
ДокументНаіменованіе реквізітаОбозначеніе реквізітаФункціональние залежності Таксофони Код таксофона Адреса таксофона Код АТСКод_такс Адреса Код_АТССчетчік ключ
2.3 Нормалізація проекту бази даних
Нормальна форма - властивість відносини в реляційної моделі даних, що характеризує його з погляду надмірності, потенційно приводить до логічно помилкових результатів вибірки або зміни даних. Нормальна форма визначається як сукупність вимог, яким має задовольняти ставлення.
Процес перетворення відносин бази даних (БД) до виду, відповідальному нормальним формам, називається нормалізацією . Нормалізація призначена для приведення структури БД до виду, що забезпечує мінімальну логічну надмірність, і не має на меті зменшення або збільшення продуктивності роботи або ...
