База даних "Облік діяльності Ощадбанку"

УКООПСПІЛКА

Полтавський університет споживчої кооперації України

Кафедра економічної кібернетики

КУРСОВИЙ ПРОЕКТ

з дисципліни ” Бази даних та інформаційні системи”

на тему: Облік діяльності Ощадбанку

Виконав студент групи ЕК-32

спеціальності „Економічна кібернетика”

Плюшко К.О.

Підпис

Керівник: асистент

науковий ступінь, вчене звання, посада

Бут А.М.

ПОЛТАВА-2006

Зміст

• Вступ
• Розділ 1
• Етап 1. Визначення типів сутностей
• Етап 2. Визначення типів зв'язків
• Етап 3. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків
• Етап 4.Визначення доменів атрибутів
• Етап 5.Визначення атрибутів, що є потенційними і первинними ключами
• Етап 6. Спеціалізація/генералізація типів сутностей
• Етап 7. Створення діаграми „сутність-зв'язок”
• Етап 8. Обговорення локальної концептуальної моделі даних з користувачами
• Розділ 2. Логічне проектування навчальної бази даних "Облік роботи ощадбанку"
• Етап 1. Логічне проектування учбової бази даних “Облік діяльності ощадбанку”
• Етап 2. Побудова і перевірка локальної логічної моделі даних для представлення користувача Завідувач аптеки
• Етап 2.1 Перетворення локальної концептуальної моделі даних у локальну логічну модель
• Етап 2.2 Перевірка моделі у відношенні транзакцій представників
• Етап 2.3 Визначення вимог підтримки цілісності даних
• Етап 2.4 Обговорення розроблених локальних логічних моделей даних з кінцевими користувачами
• Етап 3. Створення і перевірка глобальної логічної моделі даних
• Етап 3.1 Злиття локальних логічних моделей даних у єдину глобальну модель даних
• Етап 3.2 Перевірка глобальної логічної моделі даних
• Етап 3.3 Створення остаточного варіанта діаграми „сутність - зв'язок"
• Етап 3.4 Обговорення глобальної логічної моделі даних з користувачами
• Висновки
• Список літератури

Вступ

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

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

Запропонована у даних вказівках методологія роботи з реляційними Системами Управління Базами Даних (далі - СУБД), які домінують у наш час, успішно пройшла перевірку часом як у практичному, так і в науковому середовищі. Проектування баз даних складається з трьох фаз: концептуальної, логічної та фізичної. Перша фаза передбачає створення концептуальної моделі даних, яка не залежить від будь-яких фізичних характеристик засобів реалізації. У другій фазі концептуальна модель піддається доробці за допомогою видалення елементів, які не можуть бути реалізовані в реляційних системах. У третій фазі логічна модель даних перетворюється у фізичний проект, який призначено для реалізації у конкретній цільовій СУБД.

Кожну з фаз наведеної методології представлено у вигляді послідовності етапів. Недосвідчений проектувальник буде виконувати ці етапи у наведеній послідовності, дотримуючись вказаного порядку. Більш досвідчений розробник не буде жорстко додержуватись даної методології - він скоріше буде використовувати її як деяку основу або контрольний перелік необхідних дій.

Термінологія при плануванні, проектуванні та адмініструванні бази даних

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

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

База даних є фундаментальним компонентом інформаційної системи, а її розроблення і використання варто розглядати з погляду можливого розширення організації. Отже, життєвий цикл інформаційної системи організації нерозривно зв'язаний із життєвим циклом бази даних.

Основні етапи життєвого циклу програми бази даних включають: планування розроблення бази даних, визначення вимог до системи, збір і аналіз вимог користувачів, проектування бази даних, вибір цільової СУБД (у разі потреби), розроблення програм, створення прототипів (у разі потреби), реалізацію, конвертування і завантаження даних, тестування, експлуатацію і супровід.

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

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

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

Проектування бази даних включає створення проекту бази даних, призначеної для підтримки функціонування організації і досягнення її бізнес-цілей. Цей етап охоплює концептуальне, логічне і фізичне проектування бази даних.

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

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

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

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

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

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

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

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

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

Логічне проектування бази даних - це процес створення моделі використання інформації в організації, побудованої з урахуванням обраної моделі представлення даних у базі, але незалежно від особливостей конкретної цільової СУБД і інших фізичних подробиць реалізації.

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

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

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

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

Хоча вибір СУБД виконується не так вже й часто - звичайно тільки при розширенні масштабів чи підприємства при заміні існуючих систем, - усе-таки цей етап роботи іноді доводиться виконувати для оцінки нових СУБД. Його ціль полягає у виборі системи, що задовольняє поточним і майбутніми вимогами організації, а також має оптимальну вартість, включаючи витрати на придбання СУБД і будь-якого іншого додаткового програмного/апаратного забезпечення, а також витрати на заміну системи і перенавчання персоналу.

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

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

Основні поняття ER-моделювання

Тип сутності - це об`єкт чи поняття, що характеризується незалежним існуванням (з погляду даної організації).

Сутністю називається окремий екземпляр типу сутності, що може бути ідентифікований унікальним образом.

Слабкий тип сутності - це сутність, існування якої залежить від іншої сутності, а сильний тип сутності - це сутність, існування якої не залежить ні від якої іншої сутності.

Атрибутом називається властивість типу сутності чи типу зв'язку.

Домен атрибута являє собою безліч значень, що можуть бути привласнені даному атрибуту.

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

Складений атрибут складається з декількох компонентів, кожний із яких характеризується незалежним існуванням.

Однозначний атрибут - це атрибут, що містить по одному значенню для кожної сутності.

Багатозначний атрибут - це атрибут, що містить кілька значень для кожного екземпляра сутності.

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

Потенційним ключем називається атрибут чи набір атрибутів, що унікальним образом ідентифікують окремі екземпляри типу сутності.

Первинним ключем називається деякий обраний потенційний ключ сутності.

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

Типом зв'язку називається набір осмислених асоціацій між типами сутностей.

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

Ступенем типу зв'язку називається кількість сутностей-учасників даного зв'язку.

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

Показник кардинальності описує кількість можливих зв'язків для кожної сутності-учасниці.

Ступінь участі визначає, чи буде існування сутності залежати від зв'язку з деякою іншою сутністю.

Пастка розгалуження виникає, якщо в моделі даних представлений деякий зв'язок між типами сутностей, але шлях між деякими екземплярами сутності визначений неоднозначно.

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

Суперкласом називається тип сутності, що містить різні підкласи, які потрібно представити в даній моделі даних.

Підкласом називається тип сутності, що відіграє окрему роль і є членом суперкласу.

Спеціалізація - це процес виявлення максимально можливої кількості розходжень між членами сутності шляхом виділення їхніх різних рис.

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

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

Нормалізація - одним рядком

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

Відношення з надмірністю даних можуть страждати від аномалій відновлення, що поділяються на аномалії вставки, видалення і відновлення даних.

Однією з основних концепцій нормалізації є функціональна залежність, що описує зв'язок між атрибутами відношень. Нехай А і В - це атрибути деякого відношення R. Атрибут В функціонально залежить від атрибута А (що позначається як А В), якщо кожне значення А зв'язане з одним значенням В. (Причому кожний з атрибутів А і В може складатися з одного чи декількох атрибутів)

Детермінантом називається будь-який атрибут, від якого цілком функціонально залежить якийсь інший атрибут. У визначенні функціональної залежності термін "детермінант" характеризує один чи кілька атрибутів, розташованих з лівого боку від стрілки. Процес нормалізації полягає в перетворенні відношення в різні нормальні форми. На кожному етапі цього процесу віддаляються небажані характеристики відношення, що визначають його уразливість стосовно аномалій відновлення. В міру просування до більш високих нормальних форм формат представлення відношення стає більш строгим, а воно саме - менш уразливим стосовно аномалій відновлення.

Спочатку були запропоновані тільки перша (1НФ), друга (2НФ) і третя (ЗНФ) нормальні форми. Потім Вайсом і Коддом було сформульовано більш строге визначення третьої нормальної форми, що одержало назву нормальної форми Бойса-Кодда (НФБК). Усі ці нормальні форми призначені для усунення різних видів небажаних функціональних залежностей між атрибутами відношення.

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

Першою нормальною формою (1НФ) називається відношення, у якому на перетинанні кожного рядка і кожного стовпця розташовується одне і тільки одне значення.

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

Повна функціональна залежність для атрибутів А і В деякого відношення означає наступне: атрибут В цілком функціонально залежить від атрибута А, якщо атрибут В функціонально залежить від атрибута А, але не залежить ні від якої підмножини атрибута А.

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

Транзитивна залежність для атрибутів А, В і С деякого відношення означає наступне: якщо А В і В С, то С транзитивно залежить від атрибута А через атрибут В (за умови, що А функціонально не залежить від В чи С).

Нормальною формою Бойса-Кодда (НФБК) називається відношення, у якому кожен детермінант є потенційним ключем.

Четвертою нормальною формою (4НФ) називається відношення, що знаходиться в нормальній формі Бойса-Кодда і не містить нетривіальних багатозначних залежностей. Багатозначна залежність представляє таку залежність між атрибутами А, В і С деякого відношення, при якій для кожного значення атрибута А існують відповідні набори значень атрибутів В і С, причому обоє цих набори не залежать один від одного.

П'ятою нормальною формою (5НФ) називається відношення, що не містить залежностей з'єднання.

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

1. Концептуальне проектування навчальної бази даних "Облік діяльності ощадбанку"

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

Специфікація вимозі представлення користувача

"Економіст відділу грошових внесків"

Виконання фази збору й аналізу вимог 1-го представлення, що є першою в циклі розроблення програм роботи з базами даних, здійснювалося у ощадбанку. Було проведено опитування співробітників, а також проаналізовано всю документацію, яка використовувалася, або була створена працівниками при виконанні службових обов'язків. Результатом виконання цієї фази розроблення проекту з'явилася підготовка специфікацій вимог для представлення "Економіст відділу грошових внесків", характерних для даного банку. У цих специфікаціях зафіксовані вимоги до інформації, що буде вміщена в створювану базу даних, а також визначені всі трансакції, необхідні економісту відділу грошових внесків для обліку діяльності банку.

Вимоги до даних

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

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

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

Інформація, що описує кожного клієнта банку, включає в себе:

ім'я клієнта (Прізвище та ініціали);

повне ім'я клієнта;

дату проведення банківської операції;

вид операції (надання позики, депозитний рахунок і т. ін);

номер договору з клієнтом;

дату реєстрації клієнта у банку;

персональні дані клієнта: фізична особа (серія та номер паспорту, ідентифікаційний номер, повна адреса проживання, поштова адресу та контактний телефон домашній і мобільний; місце роботи); юридична особа (назва підприємства, І П Н, Код ЗКПО, р/р у банку та МФО банку, телефон/факс, юридична та фізична адреса, номер свідоцтва платника ПДВ (якщо є)).

5. В обов'язок економіста входить наступне:

обслуговування клієнтів - фізичних та юридичних осіб

оформлення договорів

ідентифікація клієнта за його персональними даними

знання банківських тарифів, процентних ставок, нормативної бази (законів, постанов, норм, внутрішніх постанов та технічних карт)

виконання трансакцій та інших банківських операцій

підпорядкування завідуючому відділу кредитування.

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

Етап 1. Побудова локальної концептуальної моделі даних для першого представлення " економіст відділу грошових внесків ".

Приступаючи до розроблення локальної концептуальної моделі даних для представлення користувача "економіст відділу грошових внесків" варто виявити різні компоненти цієї моделі, використовуючи наявні специфікації вимог користувача. У кожну створювану модель даних входять наступні компоненти:

типи сутностей;

типи зв'язків;

атрибути;

домени атрибутів;

потенційні ключі;

первинні ключі.

Розділ 1

Етап 1. Визначення типів сутностей

Почнемо роботу з того, що визначимо основні типи сутностей, виходячи з наявних специфікацій. У специфікаціях сутності звичайно представлені як іменники або вирази, що містять іменники. Аналіз показує, що основними сутностями, що згадуються в специфікаціях, є наступні:

економіст відділу;

завідувач відділу;

клієнт;

укладений договір;

філіал банку.

Документування виділених типів сутностей

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

Етап 2. Визначення типів зв'язків

Наступне завдання полягає у визначенні типів зв'язків, що існують між окремими сутностями. Як правило, зв'язки виражаються дієсловами або дієслівними сполученнями. Для виявлення всіх можливих типів зв'язків знову звернемося до специфікацій. Результати аналізу представлені в таблиці.

Таблиця 1.1 Основні типи зв'язків, виділені в специфікаціях для користувача "Економіст відділу грошових внесків"

Визначення кардинальності і рівня участі окремих типів зв'язків

Наступний крок - визначення кардинальності і рівня участі для кожного типу зв'язків, наведених у табл.1.

Кардинальність будь-якого зв'язку може мати значення або "Один до одного" (1:

1), або "один до багатьох" (1: М), або "багато до багатьох" (M: N). Для кожного зв'язку потрібно вказати його кардинальність і, якщо це можливо, верхній або нижній ліміти груп "М". Участь кожного з членів зв'язку може бути визначена або як повна (тотальна), або як часткова. Якщо зведень, що утримуються в специфікаціях, не досить для однозначного визначення властивостей деяких зв'язків, для прояснення ситуації варто звернутися до користувачів.

Зв'язок „Філіал Ощадбанку має економіста грошових внесків”. У специфікаціях цей зв'язок визначається наступною фразою: "Кожен філіал Ощадбанку має персонал..." Іншими словами, кожен з філіалів ощадбанку має трохи працівників і, отже, кардинальність даного зв'язку треба визначити як 1: М. Оскільки кожна з філій має свій персонал, ступінь участі сутності „філіал ощадбанку" у зв'язку „Має” є повною.

Щоб краще розібратися в суті даного зв'язку, розглянемо його в зворотному напрямі - „ економіста грошових внесків працює у Ощадбанку ”. Текст специфікацій не містить явного опису зв'язку „працює”, тому варто звернутися до клієнтів і задати їм питання, що нас цікавлять.

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

Відповідь. Так.

Отримана відповідь указує, що кожен економіст відділу грошових внесків може працювати тільки в одному з філій ощадбанку, і, отже, зв'язок „працює" має кардинальність 1:

1. Оскільки всі економісти працюють у певному філіалі, ступінь участі сутності „ економіст грошових внесків ” у зв'язку „Працює" буде повною.

Остаточний варіант кардинальності і ступеня участі сторін зв'язку „Філіал Ощадбанку має економіста грошових внесків" показаний на рис.1.

Щоб зробити ER-діаграму більш зрозумілою кінцевому користувачеві, дуже важливо використовувати відповідний спосіб іменування сутностей і зв'язків.

Етап 3. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків

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

Зведення про виділені атрибути і їх приналежність відповідним сутностям та зв'язкам наведені в табл.1.2

Таблиця 1.2 Атрибути які належать сутностям

Документування виділених атрибутів.

У документацію необхідно помістити докладні зведення про атрибути, перераховані у табл.2. Для кожного атрибута варто вказати загальний опис, тип даних і довжину значення, наявні обмеження, значення за замовчуванням (якщо таке є), псевдоніми (якщо такі існують), а також є атрибут складеним або похідним і чи припустиме для нього значення NULL. Фрагмент подібного документа наведений у кінці цього розділу.

Етап 4.Визначення доменів атрибутів

На цьому етапі потрібно визначити домени атрибутів, поміщених у локальну концептуальну модель даних для користувача "Економіст відділу грошових внесків". Доменом називають безліч припустимих значень для одного або більше атрибутів. Наприклад, домен атрибута Номер сутності Філіал Ощадбанку складається з рядків довжиною до двох символів, що мають значення від '11' до '99'.

Прикладом домену, поділюваного декількома атрибутами, є домен значень адрес. Атрибути Адреса, що належать сутностям філіал Ощадбанку, економіст відділу грошових внесків, мають той самий загальний домен припустимих значень.

Документування доменів атрибутів.

Приклади доменів деяких атрибутів локальної концептуальної моделі даних користувача Диспетчер наведені наприкінці даної курсової роботи.

Етап 5.Визначення атрибутів, що є потенційними і первинними ключами

Визначення потенційних ключів і вибір первинних ключів.

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

Таблиця 1.3 Сутності і їх первинні й альтернативні ключі

Документування ключів

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

Етап 6. Спеціалізація/генералізація типів сутностей

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

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

Як показано в таблиці 1.2, частина атрибутів сутності економіст, включаючи і первинний ключ, присутні також у сутностях клієнт, завідувач відділу. Сутність економіст має єдиний додатковий атрибут, пов'язаний з ім'ям номер. Сутність завідувач відділу має єдиний додатковий атрибут, пов'язаний з ім'ям № філіалу. Однак, як сутність економіст та зав. відділу, так і сутність клієнт беруть участь у різних зв'язках, наприклад у таких, як економіст укладає договір, клієнт володіє ним і зав. відділу підписує. На підставі цих зведень ми приймаємо рішення провести генералізацію сутностей економіст, завідувач і клієнт. Вони будуть представлені як підкласи суперкласу Економіст. Зв'язки, що суперклас "підтримує" зі своїми підкласами, є частковими і непересічними. Подібний варіант представлення дуже зручний при відображенні атрибутів сутностями економіст, Завідувач відділу і клієнт - як показано на рисунку 6.

Рис.6. Суперклас „Економіст відділу грошових внесків” і його підкласи „Клієнт” і „Завідувач відділу кредитування”

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

Етап 7. Створення діаграми „сутність-зв'язок”

З метою одержання наочного представлення основних сутностей і зв'язків, визначених у специфікаціях для користувача Економіст відділу грошових внесків, ми побудували вихідну ER-діаграму. Ця ER-діаграма і підготовлена на етапі 1. Документацією (у сукупності) являють собою локальну концептуальну модель даних для користувача Економіст відділу грошових внесків програми “Облік діяльності ощадбанку"

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

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

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

Додаток 1.1 Відомості про типи сутностей, які поміщено в документацію для представлення "Економіст відділу грошових внесків".

Додаток 1.2 Зведення про типи зв'язків, поміщені в документацію для представлення “Диспетчер”

Додаток 1.3 Зведення про домени атрибутів поміщених у документацію для представлення "Економіст відділу грошових внесків"

Додаток 1.4 Зведення про атрибути, поміщені в документацію для представлення "Економіст відділу грошових внесків" програми "Облік діяльності Ощадбанку"

Розділ 2. Логічне проектування навчальної бази даних "Облік роботи ощадбанку"

Етап 1. Логічне проектування учбової бази даних “Облік діяльності ощадбанку”

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

Етап 2. Побудова і перевірка локальної логічної моделі даних для представлення користувача Завідувач аптеки

На цьому етапі ми переробимо локальну концептуальну модель даних представлення економіст з метою видалення з неї всіх елементів, що ускладнюють реалізацію даної моделі в середовищі реляційних СУБД. Крім того, ми перевіримо створену логічну модель даних, застосувавши до неї правила нормалізації і контролю можливості виконання всіх необхідних представникові завідувач відділу трансакцій у тому вигляді, у якому вони описані в специфікаціях. Після завершення процесу перетворення структури концептуальної моделі з метою задоволення вимог, пропонованих до структури даних з боку реляційних СУБД, ми будемо посилатися на перетворену модель як на логічну модель даних. Кінцевою метою виконання даного етапу є створення коректної, повної і точної локальної логічної моделі даних для представлення економіст з програми "Облік діяльності Ощадбанку".

Етап 2.1 Перетворення локальної концептуальної моделі даних у локальну логічну модель

На цьому етапі ми займемося перетворенням концептуальної моделі даних з метою видалення з неї всіх структур, реалізація яких у СУБД реляційного типу є складною. Бажаний результат може бути досягнутий за допомогою виконання таких дій, як:

Видалення зв'язків типу N: N.

Видалення складних зв'язків.

Видалення рекурсивних зв'язків.

Видалення зв'язків, що мають атрибути.

Видалення множинних атрибутів.

Повторний огляд зв'язків типу 1:

1.

Видалення надлишкових зв'язків. .

Етап 2.1.2 Видалення складних зв'язків

На цьому етапі проводиться видалення будь-яких складених (не бінарних) зв'язків, що існують у концептуальній моделі. Однак на ER-діаграмі, зв'язки подібного типу відсутні. Усі зв'язки в концептуальній моделі представлення Провізор є бінарними. Іншими словами, будь-який зв'язок у цій концептуальній моделі існує тільки між двома сутностями.

Етап 2.1.3 Видалення рекурсивних зв'язків

Рекурсивним називається такий зв'язок, у якого певна сутність пов'язана сама з собою. Це такі, як наприклад: “Працівник керує Працівником". Оскільки Завідувач відділу є працівником банку і економіст є працівником банку.

Етап 2.1.4 Видалення зв'язків, що мають атрибути

Присутність зв'язків з атрибутами може вказувати на наявність у моделі ще не виділених сутностей.

Етап 2.1.5 Видалення множинних атрибутів

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

Етап 2.1.6 Повторний огляд зв'язків типу 1: 1

У деяких випадках сутності, що беруть участь у зв'язку 1: 1 присутні, тому ми їх видаляємо і переходимо до наступного етапу, це такі як: Клієнт підписує договір, економіст підписує договір, банк має зав. відділу кредитування та ін.

Етап 2.1.7 Видалення надлишкових зв'язків

У базі даних перевіряється чи існують такі зв'язки і якщо вони є, то видаляються з створеної бази даних.

Етап 2.1.8 Створення діаграми „сутність-зв'язок"

ER-діаграма, що представляє локальну концептуальну модель даних для представлення економіст відділу грошових внесків програми " Облік діяльності Ощадбанку", була показана на Рис.6 При виконанні етапу 2.1 ця модель була переглянута і модифікована з метою усунення структур даних, реалізація яких у середовищі реляційних СУБД ускладнена. Вид модифікованої моделі даних, з обліком усіх внесених до неї змін, показаний на рис.7. Отриману в результаті внесення змін модель даних правильніше буде називати локальною логічною моделлю даних представлення економіст відділу грошових внесків програми "Облік роботи Ощадбанку".

Дуже важливо також внести всі необхідні зміни в додану до логічної моделі даних документацію. Ці зміни повинні відбивати результати модифікації моделі, виконаної на даному етапі.

Документування створених відношень і атрибутів зовнішніх ключів

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

Етап 2.2 Перевірка моделі у відношенні транзакцій представників

Призначення цього етапу складається в перевірці локальної логічної моделі даних представлення економіст відділу грошових внесків у відношенні можливості виконання всіх транзакцій, передбачених специфікаціями. Для цієї мети ми використовуємо ER-діаграму, а також додану до неї документацію. Виходячи з цих даних, ми зробимо спробу виконати кожну з транзакцій вручну. Якщо це виявиться можливим для всіх транзакцій, необхідних відповідно до специфікацій, то можна вважати, що дана логічна модель успішно перевірена. Якщо ж виконати вручну якусь із транзакцій виявиться неможливим, виходить, що у логічній моделі даних є помилка, яку варто усунути. Імовірніше всього, у моделі відсутня необхідна сутність, зв'язок або атрибут. У той же час, якщо деяка частина логічної моделі виявиться зайвою для виконання всього набору необхідних транзакцій, навіть з урахуванням можливості його розширення в майбутньому, є всі підстави думати, що ця частина моделі є надлишковою і підлягає видаленню з остаточного варіанта логічної моделі даних.

Етап 2.3 Визначення вимог підтримки цілісності даних

На цьому етапі ми займемося визначенням тих вимог підтримки цілісності даних, які необхідно реалізувати в локальній логічній моделі даних користувача економіст відділу грошових внесків. Їхнє призначення полягає в підтримці постійної внутрішньої погодженості інформації, організованої у вигляді бази даних. На цьому етапі наше завдання полягає в тому, щоб установити, які саме вимоги підтримки цілісності даних необхідні, а питання методів їх реалізації будуть вирішуватися пізніше. Ми розглянемо п'ять типів вимог підтримки цілісності:

обов'язкові дані;

обмеження для доменів атрибутів;

цілісність сутностей;

посилальна цілісність;

вимоги до даного складу аптеки.

Обов'язкові дані

Необхідно встановити, які з атрибутів завжди повинні містити одне з припустимих значень. Іншими словами, нас цікавлять атрибути, що завжди повинні мати конкретні значення, відмінні від NULL. Наприклад, атрибути номер, Ім'я сутності економіст відділу грошових внесків завжди повинні містити значення, відмінні від порожнього. Однак на атрибут телефон цієї ж сутності дана вимога не поширюється, і цей атрибут цілком може мати значення NULL, а це означає, що економіст відділу грошових внесків на даний час не має телефона.

Докладні зведення про атрибути, що входять у локальну модель даних представника економісту відділу грошових внесків, були наведені при виконанні етапу 1.3 і представлені в додатку 1.4

Обмеження для доменів атрибутів

Домен атрибута встановлює набір припустимих значень, що можуть привласнюватися цьому атрибутові. Наприклад, набір припустимих значень для атрибута Номер сутності економіст відділу грошових внесків являє собою всі можливі рядки довжиною до 2 символів, що мають значення від 1 до 99. Приклади доменів атрибутів логічної моделі даних представника економіст відділу грошових внесків були наведені при виконанні етапу 1.4 і представлені в додатку 1.4 до концептуального проектування БД.

Цілісність сутностей

Атрибут первинного ключа сутності не може мати значення NULL. Наприклад, кожен екземпляр сутності філіал Ощадбанку обов'язково повинен мати конкретне значення атрибута його первинного ключа Номер_філіалу. Атрибути, що входять у значення первинного ключа кожної сутності, були визначені при виконанні етапів 1.5 і 2.2 Докладні зведення про ключі сутностей представлені в додатку 1 до цієї курсової роботи.

Посилальна цілісність

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

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