База даних стоматологічного кабінету
Концептуальне та логічне проектування навчальної бази даних "Ведення обліку обслуговування клієнтів стоматологічного кабінету". Створення і перевірка глобальної логічної моделі даних. Обговорення глобальної логічної моделі даних з користувачами.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | украинский |
| Дата добавления | 20.02.2010 |
| Размер файла | 80,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
3
УКООПСПІЛКА
Полтавський університет споживчої кооперації України
Кафедра економічної кібернетики
КУРСОВИЙ ПРОЕКТ
з дисципліни ”Проектування бази даних ”
на тему:
База даних стоматологічного кабінету
Виконала студентка групи ЕК-32
спеціальності „Економічна кібернетика”
Міщенко А.В.
Керівник: асистент
науковий ступінь, вчене звання, посада
Бут А.Н.
Полтава - 2006
Зміст
- Вступ
- Розділ 1. Концептуальне проектування навчальної бази даних “Ведення обліку обслуговування клієнтів стоматологічного кабінету”
- 1.1 Основні визначення та поняття
- 1.2 Основні поняття ER-моделювання
- 1.3 Застосування методології концептуального проектування баз даних
- 1.3.1 Етап 1. Побудова локальної концептуальної моделі даних для представлення користувача "Завідувач відділення".
- 1.3.2 Етап 2. Визначення типів сутностей
- 1.3.3 Етап 3. Визначення типів зв'язків
- 1.3.4 Етап 4. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків
- 1.3.5 Етап 4. Визначення доменів атрибутів
- 1.3.6. Етап 5. Визначення атрибутів, що є потенційними і первинними ключами
- 1.3.7 Етап 7. Обговорення локальної концептуальної моделі даних з користувачами
- Розділ ІІ. Логічне проектування бази даних
- 2.1 Логічне проектування бази даних "Ведення обліку обслуговування клієнтів стоматологічного кабінету"
- 2.1.1 Етап 1. Побудова і перевірка локальної логічної моделі даних для представлення користувача Завідувач стоматологічного кабінету
- 2.1 2 Етап 2 Перетворення локальної концептуальної моделі даних у локальну логічну модель
- 1.2.3 Етап 3. Перевірка моделі у відношенні транзакцій користувачів
- 1.2.4 Етап 4. Визначення вимог підтримки цілісності даних
- 2.1 5Етап 5. Обговорення розроблених локальних логічних моделей даних з кінцевими користувачами
- Розділ III. Створення і перевірка глобальної логічної моделі даних
- 3.1 Етап 1. Злиття локальних логічних моделей даних у єдину глобальну модель даних
- 3.2 Етап 2. Перевірка глобальної логічної моделі даних
- 3.3 Етап 3. Створення остаточного варіанта діаграми „сутність - зв'язок"
- 3.4 Етап 4. Обговорення глобальної логічної моделі даних з користувачами
- 3.4 Етап 4. Обговорення глобальної логічної моделі даних з користувачами
- Висновок
- Список літературних джерел
- Додатки
Вступ
Історія досліджень систем баз даних - це за своєю суттю історія розвитку програмного забезпечення, яке на сьогоднішній день досягло виняткової потужності та продуктивності, що зробило великий вплив на економіку. Досягнення в дослідженнях баз даних стало основою фундаментальних розробок комунікаційних систем, транспорту та логістики, фінансового менеджменту, систем із базами знань, а також великої кількості програм у цивільних та військових установах. Вони також стали основою значного прогресу в провідних галузях науки - від інформатики до медицини.
Можна стверджувати, що поява баз даних стало найвагомішим досягненням в галузі програмного забезпечення. Бази даних є основою інформаційних систем, і це докорінно змінило характер роботи багатьох організацій та установ.
Запропонована у даних вказівках методологія роботи з реляційними Системами Управління Базами Даних (далі - СУБД), які домінують у наш час, успішно пройшла перевірку часом як у практичному, так і в науковому середовищі. Проектування баз даних складається з трьох фаз: концептуальної, логічної та фізичної. Перша фаза передбачає створення концептуальної моделі даних, яка не залежить від будь-яких фізичних характеристик засобів реалізації. У другій фазі концептуальна модель піддається доробці за допомогою видалення елементів, які не можуть бути реалізовані в реляційних системах. У третій фазі логічна модель даних перетворюється у фізичний проект, який призначено для реалізації у конкретній цільовій СУБД.
Кожну з фаз наведеної методології представлено у вигляді послідовності етапів. Недосвідчений проектувальник буде виконувати ці етапи у наведеній послідовності, дотримуючись вказаного порядку. Більш досвідчений розробник не буде жорстко додержуватись даної методології - він скоріше буде використовувати її як деяку основу або контрольний перелік необхідних дій.
Тема даної курсової роботи проектування бази даних стоматологічного кабінету. Кожний стоматологічний кабінет, яким би він не був за своєю величиною має на меті прискорювати процеси своєї діяльності, що прямо залежить з його прибутковістю та конкурентною здатністю із іншими стоматологічними кабінетами. Виходячи з цього виникає потреба задоволення цієї вимоги, але це веде до того, що потрібно контролювати якість послуг та мати гарне обладнання, звичайно для цього в стоматологічних кабінетах працюють відповідні люди, але за цим не так легко прослідкувати і тому виходом з цієї ситуації є використання баз даних. Мета цієї курсової роботи створити базу даних стоматологічного кабінету якою б користувалися завідувач відділення та завідувач стоматологічного кабінету.
Розділ 1. Концептуальне проектування навчальної бази даних “Ведення обліку обслуговування клієнтів стоматологічного кабінету”
1.1 Основні визначення та поняття
Перед тим, як перейти до безпосередньої розробки бази даних, розглянемо основні поняття та визначення.
Термінологія при плануванні, проектуванні та адмініструванні бази даних
Інформаційна система є набором ресурсів, що дозволяють збирати, підтримувати актуальність, контролювати і поширювати інформацію всередині організації.
Комп'ютеризована інформаційна система включає такі компоненти, як: база даних, програмне забезпечення бази даних, прикладне програмне забезпечення, комп'ютерне устаткування з пристроями збереження даних, а також персонал, який використовує і розробляє систему.
База даних є фундаментальним компонентом інформаційної системи, а її розроблення і використання варто розглядати з погляду можливого розширення організації. Отже, життєвий цикл інформаційної системи організації нерозривно зв'язаний із життєвим циклом бази даних.
Основні етапи життєвого циклу програми бази даних включають: планування розроблення бази даних, визначення вимог до системи, збір і аналіз вимог користувачів, проектування бази даних, вибір цільової СУБД (у разі потреби), розроблення програм, створення прототипів (у разі потреби), реалізацію, конвертування і завантаження даних, тестування, експлуатацію і супровід.
Планування розроблення бази даних являє собою сукупність організаційних дій, що дозволяють із максимальною ефективністю реалізувати етапи створення програми бази даних.
Визначення вимог до системи включає визначення предметної області і границь програми бази даних, у тому числі основних областей його застосування і користувальницьких груп.
Збір і аналіз вимог користувачів являє собою процес збору й аналізу інформації про ту частину організації, що буде обслуговуватися створюваним додатком баз даних, а також використання цієї інформації для визначення вимог користувачів до нової системи.
Проектування бази даних включає створення проекту бази даних, призначеної для підтримки функціонування організації і досягнення її бізнес-цілей. Цей етап охоплює концептуальне, логічне і фізичне проектування бази даних.
Вибір цільової СУБД передбачає вибір найбільш прийнятної цільової СУБД, що буде використовуватися для підтримки програм баз даних.
Розроблення програм включає проектування інтерфейсу користувача і прикладних програм, що використовують і обробляють інформацію в базі даних.
Створення прототипів означає побудову робочих моделей програм баз даних, що дозволяють проектувальникам та майбутнім користувачам візуально ознайомитися із системою й оцінити її можливості.
Реалізація включає фізичне втілення розробленої бази даних і її програм, що використовуються.
Конвертування і завантаження даних передбачає перенос будь-яких існуючих даних у нову базу даних і надання будь-яким існуючим програмам вигляду, придатного для роботи з новою базою даних.
Тестування являє собою процес виконання прикладних програм із метою пошуку помилок. Для оцінки повноти і коректності створених програм баз даних можуть використовуватися різні стратегії тестування: тестування згори вниз, тестування знизу вгору, тестування потоків і інтенсивне тестування.
Експлуатація і супровід складається в промисловому використанні створеної системи, супроводжуваному постійною перевіркою її поточних показників функціонування, а також необхідною підтримкою.
Дві основні цілі моделювання даних полягають у спрощенні розуміння змісту (семантики) даних і проведенні обговорення існуючих інформаційних вимог. Модель даних полегшує розуміння змісту даних, і тому ми створюємо моделі, що дозволяють усвідомити представлення про дані кожного з існуючих типів користувачів, суть самої природи даних, що не залежить від їх фізичного представлення, а також використання цих даних різними програмами.
Концептуальне проектування бази даних являє собою процес створення моделі використання інформації в організації, що не залежить від усіх фізичних подробиць її представлення.
Логічне проектування бази даних - це процес створення моделі використання інформації в організації, побудованої з урахуванням обраної моделі представлення даних у базі, але незалежно від особливостей конкретної цільової СУБД і інших фізичних подробиць реалізації.
Логічна модель даних, що відображає безліч представлень про організацію окремих типів користувачів, називається глобальною логічною моделлю даних. Для розроблення глобальної логічної моделі даних використовуються два основних підходи: підхід на основі інтеграції представлень і централізований підхід.
Фізичне проектування бази даних являє собою процес створення опису реалізації бази даних у вторинній пам'яті. Воно включає визначення обраних структур збереження і методів доступу, що забезпечують ефективну обробку даних.
Проектування програм бази даних включає два основних етапи: проектування транзакції і проектування користувальницького інтерфейсу.
Транзакція бази даних являє собою операцію, для виконання якої потрібно здійснити доступ до бази даних. Як правило, вона є відображенням деякої події, що відбувається в реальному світі. Ціль проектування транзакцій полягає у визначенні і документуванні високорівневих характеристик транзакцій, необхідних для створюваної системи з базою даних.
Хоча вибір СУБД виконується не так вже й часто - звичайно тільки при розширенні масштабів чи підприємства при заміні існуючих систем, - усе-таки цей етап роботи іноді доводиться виконувати для оцінки нових СУБД. Його ціль полягає у виборі системи, що задовольняє поточним і майбутніми вимогами організації, а також має оптимальну вартість, включаючи витрати на придбання СУБД і будь-якого іншого додаткового програмного/апаратного забезпечення, а також витрати на заміну системи і перенавчання персоналу.
Адмініструванням даних називається керування ресурсами даних, включаючи планування бази даних, розроблення і підтримку стандартів, вимог і процедур, а також концептуальне і логічне проектування бази даних. Адміністрування даних в основному зв'язано із задачами, що виконуються на початкових етапах життєвого циклу програми баз даних.
Адмініструванням бази даних називається керування фізичною реалізацією Програм баз даних, включаючи фізичне проектування бази даних і її реалізацію, активізацію засобів підтримки цілісності і захисти даних, контроль поточної продуктивності системи і реорганізацію бази даних. Адміністрування бази даних звичайно зв'язано із задачами, що виконуються на пізніх етапах життєвого циклу програми баз даних.
1.2 Основні поняття ER-моделювання
Тип сутності - це об`єкт чи поняття, що характеризується незалежним існуванням (з погляду даної організації).
Сутністю називається окремий екземпляр типу сутності, що може бути ідентифікований унікальним образом.
Слабкий тип сутності - це сутність, існування якої залежить від іншої сутності, а сильний тип сутності - це сутність, існування якої не залежить ні від якої іншої сутності.
Атрибутом називається властивість типу сутності чи типу зв'язку.
Домен атрибута являє собою безліч значень, що можуть бути привласнені даному атрибуту.
Простий атрибут складається з одного компонента, що характеризується незалежним існуванням.
Складений атрибут складається з декількох компонентів, кожний із яких характеризується незалежним існуванням.
Однозначний атрибут - це атрибут, що містить по одному значенню для кожної сутності.
Багатозначний атрибут - це атрибут, що містить кілька значень для кожного екземпляра сутності.
Похідним атрибутом називається атрибут, що містить значення, яке обчислюється на основі значення зв'язаного з ним атрибута чи безлічі атрибутів, причому не обов'язково з тієї ж сутності.
Потенційним ключем називається атрибут чи набір атрибутів, що унікальним образом ідентифікують окремі екземпляри типу сутності.
Первинним ключем називається деякий обраний потенційний ключ сутності.
Складеним ключем є потенційний ключ, що складається з двох і більше атрибутів.
Типом зв'язку називається набір осмислених асоціацій між типами сутностей.
Зв'язком називається сукупність сутностей, що включає по одній сутності від кожного типу сутності, що беруть участь у даному зв'язку.
Ступенем типу зв'язку називається кількість сутностей-учасників даного зв'язку.
Рекурсивним зв'язком називається зв'язок, у якому та сама сутність, бере участь кілька разів у різних ролях. Рольові імена використовуються для визначення функції кожної сутності, охопленою даним зв'язком.
Показник кардинальності описує кількість можливих зв'язків для кожної сутності-учасниці.
Ступінь участі визначає, чи буде існування сутності залежати від зв'язку з деякою іншою сутністю.
Пастка розгалуження виникає, якщо в моделі даних представлений деякий зв'язок між типами сутностей, але шлях між деякими екземплярами сутності визначений неоднозначно.
Пастка розриву виникає, коли в моделі передбачається зв'язок між типами сутностей, але не існує жодного шляху між деякими екземплярами сутностей.
Суперкласом називається тип сутності, що містить різні підкласи, які потрібно представити в даній моделі даних.
Підкласом називається тип сутності, що відіграє окрему роль і є членом суперкласу.
Спеціалізація - це процес виявлення максимально можливої кількості розходжень між членами сутності шляхом виділення їхніх різних рис.
Генералізація - це процес виявлення мінімально можливої кількості розходжень між членами сутності шляхом виділення їх загальних рис.
Категоризацією називається процес моделювання єдиного підкласу зі зв'язком, що охоплює кілька суперкласів.
Нормалізація - одним рядком
Нормалізація - це метод створення набору відношень із заданими властивостями на основі вимог, пропонованих до даних в організації. Нормалізація є формальним методом, що може бути використаний для визначення складу відношень на основі їхніх ключів і існуючих функціональних залежностей між їх атрибутами.
Відношення з надмірністю даних можуть страждати від аномалій відновлення, що поділяються на аномалії вставки, видалення і відновлення даних.
Однією з основних концепцій нормалізації є функціональна залежність, що описує зв'язок між атрибутами відношень. Нехай А і В - це атрибути деякого відношення R. Атрибут В функціонально залежить від атрибута А (що позначається як А В), якщо кожне значення А зв'язане з одним значенням В. (Причому кожний з атрибутів А і В може складатися з одного чи декількох атрибутів)
Детермінантом називається будь-який атрибут, від якого цілком функціонально залежить якийсь інший атрибут. У визначенні функціональної залежності термін "детермінант" характеризує один чи кілька атрибутів, розташованих з лівого боку від стрілки. Процес нормалізації полягає в перетворенні відношення в різні нормальні форми. На кожному етапі цього процесу віддаляються небажані характеристики відношення, що визначають його уразливість стосовно аномалій відновлення. В міру просування до більш високих нормальних форм формат представлення відношення стає більш строгим, а воно саме - менш уразливим стосовно аномалій відновлення.
Спочатку були запропоновані тільки перша (1НФ), друга (2НФ) і третя (ЗНФ) нормальні форми. Потім Вайсом і Коддом було сформульовано більш строге визначення третьої нормальної форми, що одержало назву нормальної форми Бойса-Кодда (НФБК). Усі ці нормальні форми призначені для усунення різних видів небажаних функціональних залежностей між атрибутами відношення.
Ненормалізованою формою (ННФ) називається таблиця, що містить одну чи кілька повторюваних груп атрибутів.
Першою нормальною формою (1НФ) називається відношення, у якому на перетинанні кожного рядка і кожного стовпця розташовується одне і тільки одне значення.
Другою нормальною формою (2НФ) називається відношення, що знаходиться в першій нормальній формі, а кожен атрибут, що не входить у первинний ключ, цілком функціонально залежить від цього первинного ключа.
Повна функціональна залежність для атрибутів А і В деякого відношення означає наступне: атрибут В цілком функціонально залежить від атрибута А, якщо атрибут В функціонально залежить від атрибута А, але не залежить ні від якої підмножини атрибута А.
Третьою нормальною формою (ЗНФ) називається відношення, що знаходиться в першій і в другий нормальних формах, причому в ньому немає атрибутів, що не входять у первинний ключ і транзитивно залежать від цього первинного ключа.
Транзитивна залежність для атрибутів А, В і С деякого відношення означає наступне: якщо А В і В С, то С транзитивно залежить від атрибута А через атрибут В (за умови, що А функціонально не залежить від В чи С).
Нормальною формою Бойса-Кодда (НФБК) називається відношення, у якому кожен детермінант є потенційним ключем.
Четвертою нормальною формою (4НФ) називається відношення, що знаходиться в нормальній формі Бойса-Кодда і не містить нетривіальних багатозначних залежностей. Багатозначна залежність представляє таку залежність між атрибутами А, В і С деякого відношення, при якій для кожного значення атрибута А існують відповідні набори значень атрибутів В і С, причому обоє цих набори не залежать один від одного.
П'ятою нормальною формою (5НФ) називається відношення, що не містить залежностей з'єднання.
Залежність з'єднання - це така ситуація при який декомпозиція відношень може супроводжуватися генерацією помилкових рядків при зворотному з'єднанні декомпозованих відношень за допомогою операції природного з'єднання.
У цьому розділі ми на прикладі проілюструємо застосування методології концептуального проектування баз даних. Застосування методології буде показано на прикладі конкретного представлення користувача, якому було привласнене ім'я "завідувач відділення".
1.3 Специфікація вимозі представлення користувача "Завідувач відділення"
Виконання фази збору й аналізу вимог користувача, що є першою в циклі розроблення програм роботи з базами даних, здійснювалося у стоматологічному кабінеті. Було проведено опитування співробітників, а також проаналізовано всю документацію, яка використовувалася або була створена працівниками при виконанні службових обов'язків. Результатом виконання цієї фази розроблення проекту з'явилася підготовка специфікацій вимог для представлення "завідувач відділення", характерних для даного стоматологічного кабінету. У цих специфікаціях зафіксовані вимоги до інформації, що буде вміщена в створювану базу даних, а також визначені всі транзакції, необхідні завідувач відділення для обліку діяльності стоматологічного кабінету.
Вимоги до даних.
У кожному стоматологічному кабінеті є лікарі та асистенти. Всі вони розподілені по окремих відділах і знаходяться під керуванням “завідувача відділення”, що підпорядковуються “завідувачу стоматологічного кабінету".
Інформація, що описує кожного Працівника, включає особистий номер, повне ім'я (ім'я і прізвище), адресу проживання, номер телефону, дату народження, а також номер відділення стоматологічного відділу, у якому він працює, стать і посаду яку він займає. Особистий номер кожного лікаря і асистента є унікальним у межах усіх відділень.
Інформація, що описує кожне відділення, включає унікальний номер відділення, номер телефону і номер факсу.
Інформація, що описує кожного пацієнта, включає особистий номер, повне ім'я (ім'я і прізвище), адресу проживання, номер телефону, дату народження.
В обов'язок завідувача відділення входить наступне:
Слідкувати за зайнятістю працівників;
Вести облік наявності пацієнтів у стоматологічному кабінеті;
Вести облік обслуговування пацієнтів;
Та інше.
1.3 Застосування методології концептуального проектування баз даних
1.3.1 Етап 1. Побудова локальної концептуальної моделі даних для представлення користувача "Завідувач відділення"
Приступаючи до розроблення локальної концептуальної моделі даних для представлення користувача "завідувач відділення" варто виявити різні компоненти цієї моделі, використовуючи наявні специфікації вимог користувача. У кожну створювану модель даних входять наступні компоненти: типи сутностей; типи зв'язків; атрибути; домени атрибутів; потенційні ключі; первинні ключі.
1.3.2 Етап 2. Визначення типів сутностей
Почнемо роботу з того, що визначимо основні типи сутностей, виходячи з наявних специфікацій. У специфікаціях сутності звичайно представлені як іменники або вирази, що містять іменники. Аналіз показує, що основними сутностями, що згадуються в специфікаціях, є наступні:
працівник;
пацієнт;
ліки і матеріали;
відділення;
завідувач відділення.
Документування виділених типів сутностей
Документування зведень про кожну з виділених сутностей полягає в підготовці докладного визначення кожної сутності, включаючи існуючі для неї псевдоніми й опис особливостей використання. Усі зведення, поміщені в документацію на цьому етапі, наведені в додатках.
1.3.3 Етап 3. Визначення типів зв'язків
Наступне завдання полягає у визначенні типів зв'язків, що існують між окремими сутностями. Як правило, зв'язки виражаються дієсловами або дієслівними сполученнями. Для виявлення всіх можливих типів зв'язків знову звернемося до специфікацій. Результати аналізу представлені в таблиці.
Таблиця 1.1 Основні типи зв'язків, виділені в специфікаціях для користувача "завідувач відділення"
|
Тип сутності |
Тип зв'язку |
Тип сутності |
|
|
Відділення |
Має |
Працівник |
|
|
Працівник |
Відповідає за Знаходиться під керівництвом Обслуговує |
Пацієнт Завідувач відділення Пацієнт |
|
|
Завідувач відділення |
Керує |
Працівник |
|
|
Ліки і матеріали |
Використовується |
Працівник |
|
|
Пацієнт |
Отримує Обслуговується |
Ліки і матеріали (послуга) Працівник |
Визначення кардинальності і рівня участі окремих типів зв'язків.
Наступний крок - визначення кардинальності і рівня участі для кожного типу зв'язків, наведених у табл.1.
Кардинальність будь-якого зв'язку може мати значення або "Один до одного" (1:1), або "один до багатьох" (1: М), або "багато до багатьох" (M: N). Для кожного зв'язку потрібно вказати його кардинальність і, якщо це можливо, верхній або нижній ліміти груп "М". Участь кожного з членів зв'язку може бути визначена або як повна (тотальна), або як часткова. Якщо зведень, що утримуються в специфікаціях, не досить для однозначного визначення властивостей деяких зв'язків, для прояснення ситуації варто звернутися до користувачів.
Зв'язок „Відділення має Працівника ". У специфікаціях цей зв'язок визначається наступною фразою: "Кожне відділення стоматологічного кабінету має персонал..." Іншими словами, кожне з відділень стоматологічного кабінету має трохи працівників і, отже, кардинальність даного зв'язку треба визначити як 1: М. Оскільки кожне з відділень стоматологічного кабінету має персонал, ступінь участі сутності „Відділення" у зв'язку „Має” є повною.
Щоб краще розібратися в суті даного зв'язку, розглянемо його в зворотному напрямі - „ Працівник працює у відділенні”. Текст специфікацій не містить явного опису зв'язку „працює”, тому варто звернутися до користувачів і задати їм питання, що вас цікавлять.
Запитання. Кожний працівник стоматологічного кабінету працює тільки в одному відділенні?
Відповідь. Так.
Отримана відповідь указує, що кожен лікар і асистент стоматологічного кабінету може працювати тільки в одному з його відділень, і, отже, зв'язок „працює" має кардинальність 1:
1. Оскільки всі лікарі і асистенти стоматологічного кабінету працюють у якому-небудь з його відділень, ступінь участі сутності „Працівник” у зв'язку „Працює" буде повною.
3
Остаточний варіант кардинальності і ступеня участі сторін зв'язку „Відділення має Працівника ” показаний на рис.1. Щоб зробити ER-діаграму більш зрозумілою кінцевому користувачеві, дуже важливо використовувати відповідний спосіб іменування сутностей і зв'язків.
3
3
3
3
1.3.4 Етап 4. Визначення атрибутів і зв'язування їх з типами сутностей і зв'язків
Тепер нам необхідно виділити атрибути сутностей, що у специфікаціях також можуть бути представлені іменниками (або відповідними сполученнями). Атрибут описує деякий аспект визначеної сутності або зв'язку. При виконанні цього етапу варто звернути особливу увагу на ті випадки, коли визначений атрибут справляє враження, ніби він описує більше одного типу сутності або зв'язку.
Зведення про виділені атрибути і їх приналежність відповідним сутностям та зв'язкам наведені в табл.1.2
Таблиця 1.2 Атрибути які належать сутностям
|
Тип сутності |
Атрибут |
|
|
Відділення |
Номер (Номер відділення) Телефон (Номер телефону) Факс (Номер факсу) |
|
|
Працівник |
Номер Прізвище (Ім'я і Прізвище) Адреса (Вулиця, Район, Місто, Поштовий індекс) Телефон (Номер телефону) Народження (Дата народження) Стать Посада |
|
|
Завідувач відділення |
Номер (Табельний номер) Прізвище (Ім'я і Прізвище) Адреса (Вулиця, Район, Місто, Поштовий індекс) Телефон (Номер телефону) Народження (Дата народження) Стать Посада |
|
|
Ліки і матеріали |
Штрих код Назва ліків і матеріалів Умови зберігання Термін зберігання |
|
|
Пацієнт |
Номер по порядку Прізвище (Ім'я і Прізвище) Адреса (Вулиця, Район, Місто, Поштовий індекс) Телефон (Номер телефону) Народження (Дата народження) Стать |
Документування виділених атрибутів.
У документацію необхідно помістити докладні зведення про атрибути, перераховані у табл.1. .2. Для кожного атрибута варто вказати загальний опис, тип даних і довжину значення, наявні обмеження, значення за замовчуванням (якщо таке є), псевдоніми (якщо такі існують), а також є атрибут складеним або похідним і чи припустиме для нього значення NULL. Фрагмент подібного документа наведений у кінці цього розділу.
1.3.5 Етап 4. Визначення доменів атрибутів
На цьому етапі потрібно визначити домени атрибутів, поміщених у локальну концептуальну модель даних для користувача "Завідувач відділенням". Доменом називають безліч припустимих значень для одного або більше атрибутів. Наприклад, домен атрибута Номер сутності Відділення складається з рядків довжиною до трьох символів, що мають значення від '111' до '999'.
Прикладом домену, поділюваного декількома атрибутами, є домен значень адрес. Атрибути Адреса, що належать сутностям працівник, завідувач відділення, пацієнт мають той самий загальний домен припустимих значень.
Документування доменів атрибутів.
Приклади доменів деяких атрибутів локальної концептуальної моделі даних користувача завідувач стоматологічного кабінету наведені наприкінці даної глави.
1.3.6. Етап 5. Визначення атрибутів, що є потенційними і первинними ключами
Визначення потенційних ключів і вибір первинних ключів
Звернемося до табл.2 і виділимо в ній усі можливі потенційні ключі для кожної із сутностей, представлених у локальній концептуальній моделі даних користувача завідувач відділення. Потім зі знайдених потенційних ключів виберемо первинні ключі, що найбільше підходять для кожного типу сутності. Результати визначення первинних і альтернативних ключів для кожної із сутностей представлені в табл.1.3
Таблиця 1.3 Сутності і їх первинні й альтернативні ключі
|
Сутність |
Первинний ключ |
Альтернативний ключ |
|
|
Відділення |
Номер |
Телефон |
|
|
Працівник |
Табельний Номер |
||
|
Завідувач відділення |
Табельний Номер |
||
|
Пацієнт |
Номер |
||
|
Ліки і матеріали |
Штрихкод |
Документування ключів
Поміщені в документацію зведення про атрибути, що є первинними й альтернативними ключами кожної із сутностей, представлені наприкінці даної глави.
Створення діаграми „сутність-зв'язок”
З метою одержання наочного представлення основних сутностей і зв'язків, визначених у специфікаціях для користувача завідувача відділення, ми побудували вихідну ER-діаграму, яка має вигляд ця ER-діаграма і підготовлена на етапі 1 документація (у сукупності) являють собою локальну концептуальну модель даних для користувача завідувача відділення програми "Ведення обліку обслуговування клієнтів стоматологічного кабінету".
1.3.7 Етап 7. Обговорення локальної концептуальної моделі даних з користувачами
Перш ніж завершити виконання першого етапу розроблення бази даних, необхідно обговорити створені локальні концептуальні моделі з користувачами. При виявленні яких-небудь помилок варто внести в проект відповідні зміни, для чого буде потрібно повернутися до виконання попередніх етапів. Цей цикл повинен повторюватися доти, поки користувач не погодиться з тим, що запропонований йому проект правильно відбиває представлення кожного типу користувача про роботу стоматологічного кабінету.
На другому етапі проектування, передбаченому даною методологією розроблення баз даних, здійснюється логічне проектування бази даних реляційного типу. Як відправні пункти будуть використані локальні концептуальні моделі даних для користувачів завідувача відділу та завідувача магазину.
Розділ ІІ. Логічне проектування бази даних
2.1 Логічне проектування бази даних "Ведення обліку обслуговування клієнтів стоматологічного кабінету"
Далі обговоримо застосування методології логічного проектування баз даних реляційного типу. Застосування методології буде показано на прикладі конкретних представлень користувачів під іменами Завідувач відділення і Завідувач стоматологічного кабінету. Ми вже описали розроблення локальної концептуальної моделі даних для представлення користувача Завідувача відділення з програми "Ведення обліку обслуговування клієнтів стоматологічного кабінету". Тепер ми перетворимо цю модель у логічну модель даних, після чого об'єднаємо її з локальною логічною моделлю даних для представлення Завідувача стоматологічного кабінету. У результаті злиття двох локальних моделей буде отримана глобальна логічна модель даних програми "Ведення обліку обслуговування клієнтів стоматологічного кабінету", що відображає обидва представлення користувачів.
2.1.1 Етап 1. Побудова і перевірка локальної логічної моделі даних для представлення користувача Завідувач стоматологічного кабінету
На цьому етапі ми переробимо локальну концептуальну модель даних представлення Завідувач відділенням з метою видалення з неї всіх елементів, що ускладнюють реалізацію даної моделі в середовищі реляційних СУБД. Крім того, ми перевіримо створену логічну модель даних, застосувавши до неї правила нормалізації і контролю можливості виконання всіх необхідних користувачеві Завідувач віділенням транзакцій у тому вигляді, у якому вони описані в специфікаціях. Після завершення процесу перетворення структури концептуальної моделі з метою задоволення вимог, пропонованих до структури даних з боку реляційних СУБД, ми будемо посилатися на перетворену модель як на логічну модель даних. Кінцевою метою виконання даного етапу є створення коректної, повної і точної локальної логічної моделі даних для представлення користувача Завідувач відділенням з програми "Ведення обліку обслуговування клієнтів стоматологічного кабінету".
2.1 2 Етап 2 Перетворення локальної концептуальної моделі даних у локальну логічну модель
На цьому етапі ми займемося перетворенням концептуальної моделі даних з метою видалення з неї всіх структур, реалізація яких у СУБД реляційного типу є складною. Бажаний результат може бути досягнутий за допомогою виконання таких дій, як:
Видалення зв'язків типу M: N.
Видалення складних зв'язків.
Видалення рекурсивних зв'язків.
Видалення зв'язків, що мають атрибути.
Видалення множинних атрибутів.
Повторний огляд зв'язків типу 1:1.
Видалення надлишкових зв'язків. .
Видалення складних зв'язків
На цьому етапі проводиться видалення будь-яких складених (не бінарних) зв'язків, що існують у концептуальній моделі. Однак на ER-діаграмі, зв'язки подібного типу відсутні. Усі зв'язки в концептуальній моделі представлення Завідувач відділенням є бінарними. Іншими словами, будь-який зв'язок у цій концептуальній моделі існує тільки між двома сутностями.
Видалення рекурсивних зв'язків
Видалення зв'язків, що мають атрибути
Присутність зв'язків з атрибутами може вказувати на наявність у моделі ще не виділених сутностей.
Видалення множинних атрибутів
У локальній концептуальній моделі даних представлення Завідувач відділенням множинні атрибути відсутні, тому ми просто переходимо до наступного етапу.
Повторний огляд зв'язків типу 1: 1
У деяких випадках сутності, що беруть участь у зв'язку 1: 1, можуть фактично представляти різні аспекти того самого об`єкта. З цієї причини рекомендується знову проаналізувати зміст усіх зв'язків типу 1: 1, що існують у моделі даних. У нашому прикладі є зв'язок цього типу Працівник Відповідає за Пацієнта, однак зовсім очевидно, що сутності, що беруть участь у ньому, представляють різні об`єкти реального світу.
Видалення надлишкових зв'язків
Створення діаграм „сутність-зв'язок"
ER-діаграма, що представляє локальну концептуальну модель даних для представлення Завідувач відділення програми "Ведення обліку обслуговування клієнтів стоматологічного кабінету", була показана на рис.7. При виконанні етапу 2.1 ця модель була переглянута і модифікована з метою усунення структур даних, реалізація яких у середовищі реляційних СУБД ускладнена. Вид модифікованої моделі даних, з обліком усіх внесених до неї змін, показаний на рис.10. Отриману в результаті внесення змін модель даних правильніше буде називати локальною логічною моделлю даних представлення Завідувач відділення програми "Ведення обліку обслуговування клієнтів стоматологічного кабінету".
Дуже важливо також внести всі необхідні зміни в додану до логічної моделі даних документацію. Ці зміни повинні відбивати результати модифікації моделі, виконаної на даному етапі.
Документування створених відношень і атрибутів зовнішніх ключів
Опис усього набору відношень, створеного на основі локальної моделі даних представлення Завідувачем відділенням, наведено в додатку у кінці розділу. Словник даних також має бути оновлений з метою відображення в ньому всіх ключових атрибутів, знову визначених на цьому етапі. Особливу увагу варто приділити будь-якому новому первинному або альтернативному ключам, створеним у результаті експортування зовнішніх ключів з метою представлення різних зв'язків.
1.2.3 Етап 3. Перевірка моделі у відношенні транзакцій користувачів
Призначення цього етапу складається в перевірці локальної логічної моделі даних представлення Завідувач відділенням у відношенні можливості виконання всіх транзакцій, передбачених специфікаціями. Для цієї мети ми використовуємо ER-діаграму, а також додану до неї документацію. Виходячи з цих даних, ми зробимо спробу виконати кожну з транзакцій вручну. Якщо це виявиться можливим для всіх транзакцій, необхідних відповідно до специфікацій, то можна вважати, що дана логічна модель успішно перевірена. Якщо ж виконати вручну якусь із транзакцій виявиться неможливим, виходить, що у логічній моделі даних є помилка, яку варто усунути. Імовірніше всього, у моделі відсутня необхідна сутність, зв'язок або атрибут. У той же час, якщо деяка частина логічної моделі виявиться зайвою для виконання всього набору необхідних транзакцій, навіть з урахуванням можливості його розширення в майбутньому, є всі підстави думати, що ця частина моделі є надлишковою і підлягає видаленню з остаточного варіанта логічної моделі даних.
1.2.4 Етап 4. Визначення вимог підтримки цілісності даних
На цьому етапі ми займемося визначенням тих вимог підтримки цілісності даних, які необхідно реалізувати в локальній логічній моделі даних користувача Завідувач відділення. Їхнє призначення полягає в підтримці постійної внутрішньої погодженості інформації, організованої у вигляді бази даних. На цьому етапі наше завдання полягає в тому, щоб установити, які саме вимоги підтримки цілісності даних необхідні, а питання методів їх реалізації будуть вирішуватися пізніше. Ми розглянемо п'ять типів вимог підтримки цілісності:
обов'язкові дані;
обмеження для доменів атрибутів;
цілісність сутностей;
посилальна цілісність;
вимоги даного підприємства.
Обов'язкові дані
Необхідно встановити, які з атрибутів завжди повинні містити одне з припустимих значень. Іншими словами, нас цікавлять атрибути, що завжди повинні мати конкретні значення, відмінні від NULL. Наприклад, атрибути номер, Ім'я працівника сутності Працівник завжди повинні містити значення, відмінні від порожнього. Однак на атрибут телефон цієї ж сутності дана вимога не поширюється, і цей атрибут цілком може мати значення NULL, а це означає, що працівник на даний час не має телефона.
Докладні зведення про атрибути, що входять у локальну модель даних користувача Завідувач відділення, були наведені при виконанні етапу 1.3 і представлені в додатку 1.4 до концептуального проектування БД.
Обмеження для доменів атрибутів
Домен атрибута встановлює набір припустимих значень, що можуть привласнюватися цьому атрибутові. Наприклад, набір припустимих значень для атрибута Номер сутності Працівник являє собою всі можливі рядки довжиною до 4 символів, що мають значення від 1 до 9999. Приклади доменів атрибутів логічної моделі даних користувача Завідувач відділення були наведені при виконанні етапу 1.4 і представлені в додатку 1.4 до концептуального проектування БД.
Цілісність сутностей
Атрибут первинного ключа сутності не може мати значення NULL. Наприклад, кожен екземпляр сутності Відділення обов'язково повинен мати конкретне значення атрибута його первинного ключа Номер_відділення. Атрибути, що входять у значення первинного ключа кожної сутності, були визначені при виконанні попередніх етапів Докладні зведення про ключі сутностей представлені в додатку.
Посилальна цілісність
Зв'язки між сутностями моделюються за допомогою приміщення в дочірнє відношення копії первинного ключа батьківського відношення. Поняття посилальної цілісності означає, що якщо зовнішній ключ дочірнього відношення містить деяке значення, то це значення повинне посилатися на існуюче і коректне значення ключа в батьківському відношенні.
Атрибути, що входять до складу первинних і зовнішніх ключів різних сутностей, представлені в додатку 1.
Підтримка посилальної цілісності організується за допомогою завдання необхідних обмежень для значень первинних і зовнішніх ключів.
Ці обмеження визначають умови, яких слід дотримуватися при відновленні або видаленні значень первинного ключа, а також при вставці або відновленні значень зовнішнього ключа.
Відзначимо, що вставка нового значення первинного ключа або видалення значення зовнішнього ключа не викликає яких-небудь проблем з посилальною цілісністю.
Для кожного зовнішнього ключа відношення варто вказати умови, що повинні виконуватися при відновленні або видаленні відповідного значення первинного ключа. У цьому випадку можна застосувати одну з пропонованих стратегій - NO ACTION, CASCADE, SET NULL, SET DEFAULT або NO CHECK
Вимоги даного підприємства
Ці вимоги, які інакше називаються бізнес-правилами, визначаються тими методами й обмеженнями, що прийняті на даному підприємстві щодо виконання різних операцій.
Наприклад, у АТП установлено, що працівник може бути закріпленим лише за одним відділом. Усі встановлені вимоги підтримки цілісності даних для локальної моделі даних користувача Завідувач відділення повинні бути детально відображені в документації.
2.1.5Етап 5. Обговорення розроблених локальних логічних моделей даних з кінцевими користувачами
На цьому етапі виконується остаточна перевірка локальної логічної моделі даних користувача Завідувач відділенням, здійснювана за допомогою обговорення її з користувачами. Дуже важливо, щоб модель правильно відбивала те представлення про реальну ділову обстановку, що має тип користувачів, названий Завідувач відділенням. Основним критерієм обговорення для розроблювачів і користувачів є ER-діаграма. Однак не менш важливо, щоб користувачі уважно ознайомилися із супровідною документацією. Якщо в моделі або документації буде знайдена будь-яка невідповідність, усі необхідні етапи повинні бути пройдені ще раз.
3
Розділ III. Створення і перевірка глобальної логічної моделі даних
У цьому розділі ми опишемо процес злиття локальної логічної моделі даних для представлення користувача Завідувач відділенням з локальною логічною моделлю даних для представлення користувача Завідувача стоматологічного кабінету з метою побудови глобальної логічної моделі даних програми. Глобальна логічна модель даних повинна відбивати особливості представлень обох користувачів додатка "Ведення обліку обслуговування клієнтів стоматологічного кабінету". На даному етапі ми продемонструємо тільки один з можливих підходів до виконання процедури злиття декількох локальних логічних моделей даних у єдину глобальну логічну модель.
Локальні логічні моделі даних, що будуть зливатися на даному етапі, показані на рис.7 (користувач Завідувач відділенням) і рис.7 (користувач Завідувач стоматологічного кабінету).
3.1 Етап 1. Злиття локальних логічних моделей даних у єдину глобальну модель даних
На цьому етапі ми зіллємо дві локальні логічні моделі даних з метою створення глобальної логічної моделі даних, тобто глобального представлення для всього стоматологічного кабінету. Процес злиття моделей даних ми почнемо з виявлення в них подібних елементів, після чого виконаємо пошук і видалення конфліктних областей. Завершить процедуру включення в глобальну модель унікальних областей кожної з вихідних локальних моделей. Деякі типові задачі, що доводиться вирішувати під час виконання злиття, нижче будуть проілюстровані на конкретних прикладах.
Аналіз імен сутностей і їхніх первинних ключів
Порівняємо імена сутностей і визначені для них первинні ключі кожної з локальних моделей, що зливаються.
Таблиця 3.1 Порівняння імен сутностей і їхніх первинних ключів у представленнях користувачів Завідувач відділенням і Зав. стомат. кабінетом
|
Тип сутності (представлення Завідувач відділення) |
Первинний ключ |
Тип сутності (представлення Зав. стомат. кабінету) |
Первинний ключ |
|
|
Відділення |
Номер_Відділення |
Відділення |
Номер_Відділення |
|
|
Працівник |
Номер_Працівника |
Працівник |
Номер_Працівника |
|
|
Зав. відділенням |
Номер_Працівника |
Зав. відділенням |
Номер_Працівника |
|
|
Ліки і матеріали |
Номер_ Ліки і матеріали |
Ліки і матеріали |
Номер_ Ліки і матеріали |
|
|
Пацієнт |
Номер_Пацієнт |
Пацієнт |
Номер_Пацієнт |
Попереднє порівняння імен сутностей і їх первинних ключів у кожному із представлень дозволяє виявити їх загальні ділянки, тобто ті області, у яких вони перекриваються.
Аналіз імен зв'язків
Тепер порівняємо імена присутніх у представленнях Завідувач відділення і Зав. стомат. кабінету зв'язків. Імена зв'язків, що існують у кожному із представлень, показані в табл. Кожен зв'язок представлений у таблиці тільки один раз і асоційований з її батьківською сутністю.
Таблиця 3.2 Порівняння зв'язків, наявних у представленнях Завідувач відділення і Зав. стомат. кабінету.
|
Сутності (представлення завідувач відділення) |
Тип зв'язку |
Тип сутності (представлення завідувач відділення) |
Сутності (представлення Зав. стомат. кабінету) |
Тип зв'язку |
Тип сутності (представлення Зав. стомат. кабінету) |
|
|
Відділення |
Має |
Працівник |
Відділення |
Має |
Працівник |
|
|
Працівник |
Відповідає за Знаходиться під керівництвом Пропонує |
Пацієнт Заввідділення Послуги |
Працівник |
Відповідає за Знаходиться під керівництвом Пропонує |
Пацієнт Заввідділення Послуги |
|
|
Заввідділом |
Керує |
Працівник |
Заввідділом |
Керує |
Працівник |
|
|
Послуги |
Пропонує |
Працівник |
Послуги |
Пропонує |
Працівник |
|
|
Пацієнт |
Володіє Укладає |
Коштами Договір про перевезення |
Пацієнт |
Володіє Укладає |
Коштами Договір про перевезення |
|
|
Завідувач відділом |
Керує |
Відділення |
Це попереднє порівняння імен зв'язків у кожному із представлень користувачів також допомагає уточнити ділянки, спільні для обох представлень. Однак із цього зовсім не випливає що можна покладатися на те, що сутності або зв'язок з тими ж іменами відіграють однакову роль у кожному із представлень. І все-ж таки, порівняння імен сутностей і зв'язків можна вважати дуже зручною вихідною точкою пошуку ідентичних ділянок у представленнях, що зливаються, якщо, звичайно, не забувати, про можливі помилки.
Злиття загальних сутностей з окремих локальних моделей.
На даному етапі виконується перевірка імен і вмісту кожної сутності в обох представленнях. Зокрема, для ідентифікації еквівалентних сутностей з різними іменами варто проаналізувати їхні первинні ключі. Виконання даного етапу включає наступні дії:
злиття сутностей з однаковими іменами й однаковими первинними ключами;
злиття сутностей з однаковими іменами, що мають різні первинні ключі;
злиття сутностей з різними іменами, що мають однакові або різні первинні ключі.
Злиття сутностей з однаковими іменами й однаковими первинними ключами.
Сутності, що мають в обох представленнях той самий первинний ключ, як правило, представляють ту саму концепцію реального світу. Ідентифікація й об'єднання подібних пар являє собою відносно нескладну задачу.
Злиття сутностей Лікар і асистент з представлень завідувач відділенням і зав. стоматологічним кабінетом.
Представлення Завідувач відділенням
ПРАЦІВНИК (Табельний_Номер_Працівника, Прізвище, Ім'я, Адреса, Телефон, Стать, Дата народження. Посада, Номер_відділення.
Первинний ключ - Табельний_Номер_Працівника.
Зовнішній ключ - Номер_відділення посилання Відділення (Номер_відділення).
Представлення Завідувач стоматологічним кабінетом
ПРАЦІВНИК (Табельний_Номер_Працівника, Прізвище, Ім'я, Адреса, Телефон, Стать, Дата народження, Пост, Зарплата, Дата прийняття, НСН (національний страховий номер), Номер_відділення).
Первинний ключ -Табельний_ Номер_Працівника.
Альтернативний ключ - НСН.
Зовнішній ключ - Номер_відділення посилання Відділення (Номер_відділення).
Глобальне представлення
ПРАЦІВНИК (Табельний_Номер_Працівника, Прізвище, Ім'я, Адреса, Телефон, Стать, Дата народження, Пост, Зарплата, Дата прийняття, НСН (національний страховий номер), Номер_відділення).
Первинний ключ -Табельний_ Номер_Працівника.
Альтернативний ключ - НСН.
Зовнішній ключ - Номер_відділення посилання Відділення (Номер_відділення).
Подобные документы
Систематизація знань як основна функція бази даних. Логічне та фізичне проектування бази даних. Створення таблиць у базі даних, визначення основних зв'язків. Інструментальні засоби проектування та створення програмного забезпечення для обробки даних.
курсовая работа [1,4 M], добавлен 29.04.2010Побудова інформаційної системи "Магазин товарів для настільного тенісу" з автоматизації роботи магазину. Концептуальне моделювання бази даних. Обґрунтування вибору СУБД. Логічне проектування бази даних. Схема бази даних. Створення таблиць в конструкторі.
курсовая работа [8,8 M], добавлен 16.12.2015Проектування бази даних предметної області "Магазин будівельних матеріалів". Аналіз сукупності вхідних і вихідних даних, шляхи удосконалення інформаційної системи обліку товару. Організація інформаційної бази, розробка логічної і фізичної моделі.
курсовая работа [559,2 K], добавлен 09.05.2016Розробка бази даних в середовищі Microsoft SQL Server 2008 для обліку послуг фітнес-клубу. Таблиці для баз даних, їх властивості. Аналіз сукупності вхідних і вихідних параметрів, опис інформаційної бази, розробка логічної і фізичної моделі даних в ІС.
курсовая работа [449,9 K], добавлен 09.05.2016Концептуальна модель бази даних, визначення зв’язків між ними, атрибутів сутностей їх доменів. Створення ORM source model та Database model diagram для бази даних "Автотранспортне підприємство". Генерування ddl-скрипта для роботи в СУБД SQL-Server.
курсовая работа [47,3 K], добавлен 17.10.2013Специфікація вимог для кожного з двох користувачів. Концептуальне та логічне проектування баз даних. Історія досліджень баз даних (програмного забезпечення). Система упрваління базами даних. Фази проектування баз даних: концептуальна, логічна, фізична.
дипломная работа [105,8 K], добавлен 20.02.2010Розробка бази даних для меблевої фірми. Обстеження і аналіз предметної області та побудова концептуальної, логічної та фізичної моделі цієї бази даних. Використання мови програмування Visual Basic при написанні програмного коду, що обслуговує базу даних.
курсовая работа [1,4 M], добавлен 24.10.2010Специфікація вимог для кожного з двох користувачів. Концептуальне проектування бази даних. Визначення типів сутностей та зв’язків, доменів. Перетворення концептуальної моделі даних у логічну, визначення набору відношень, підтримки цілісності даних.
курсовая работа [55,1 K], добавлен 15.03.2015Аналіз відомих підходів до проектування баз даних. Ієрархічна, мережева та реляційна моделі представлення даних, їх особливості. Концептуальне проектування: приклад документів, побудова ER-діаграми, модель "сутність-зв'язок". Побудова фізичної моделі.
курсовая работа [541,5 K], добавлен 29.01.2013Системний аналіз бази даних за вхідною та вихідною документацією, визначення сутностей, атрибутів, зв’язків. Створення логічної моделі бази даних із застосуванням нормалізації, алгоритм її роботи. Розробка програмного забезпечення та інтерфейсу СУБД.
курсовая работа [946,8 K], добавлен 02.07.2015
