ПЕРЕЛІК ДИСЦИПЛІН:
  • Адміністративне право
  • Арбітражний процес
  • Архітектура
  • Астрологія
  • Астрономія
  • Банківська справа
  • Безпека життєдіяльності
  • Біографії
  • Біологія
  • Біологія і хімія
  • Ботаніка та сільське гос-во
  • Бухгалтерський облік і аудит
  • Валютні відносини
  • Ветеринарія
  • Військова кафедра
  • Географія
  • Геодезія
  • Геологія
  • Етика
  • Держава і право
  • Цивільне право і процес
  • Діловодство
  • Гроші та кредит
  • Природничі науки
  • Журналістика
  • Екологія
  • Видавнича справа та поліграфія
  • Інвестиції
  • Іноземна мова
  • Інформатика
  • Інформатика, програмування
  • Юрист по наследству
  • Історичні особистості
  • Історія
  • Історія техніки
  • Кибернетика
  • Комунікації і зв'язок
  • Комп'ютерні науки
  • Косметологія
  • Короткий зміст творів
  • Криміналістика
  • Кримінологія
  • Криптология
  • Кулінарія
  • Культура і мистецтво
  • Культурологія
  • Російська література
  • Література і російська мова
  • Логіка
  • Логістика
  • Маркетинг
  • Математика
  • Медицина, здоров'я
  • Медичні науки
  • Міжнародне публічне право
  • Міжнародне приватне право
  • Міжнародні відносини
  • Менеджмент
  • Металургія
  • Москвоведение
  • Мовознавство
  • Музика
  • Муніципальне право
  • Податки, оподаткування
  •  
    Бесплатные рефераты
     

     

     

     

     

     

         
     
    Розробка програмного забезпечення для Відділення реанімації та інтенсивної терапії новонароджених МГБ N1 м. Сургута
         

     

    Інформатика, програмування

    Міністерство загальної та професійної освіти РФ

    Сургутський державний університет

    Факультет інформаційних технологій

    Кафедра інформатики та обчислювальної техніки

    Дипломна робота

    На тему
    «Розробка програмного забезпечення для відділення реанімації та інтенсивної

    Терапії Новонароджених при Муніципальній Міський Лікарні № 1 міста

    Сургута»

    Виконав: Юрій В. Гудоніс

    Керівник: Челноков С. Б.

    Рецензент: Шепелєв А.С.

    Сургут 1998р.

    Зміст


    Вступ | 4 | |
    | Постановка завдання | 5 |


    Основи сучасних баз даних
    | | 6 |


    1. Бази даних і файлові системи
    | | 6 |


    1.1. Файлові системи
    | | 8 |

    1. Структури файлів
    | | 9 |

    2. Іменування файлів
    | | 11 |

    3. Захист файлів
    | | 13 |

    4. Режим багатокористувацького доступу
    | | 14 |

    1. Області застосування файлів
    | | 15 |

    2. Потреби інформаційних систем
    | | 16 |


    2. Функції СУБД. Типова організація СУБД. Приклади
    | | 21 |

    1. Основні функції СУБД
    | | 22 |

    1. Безпосереднє управління даними у зовнішній пам'яті
    | | 22 |

    2. Управління буферами оперативної пам'яті
    | | 22 |

    3. Управління транзакціями
    | | 23 |

    4. Журналізацію
    | | 24 |

    5. Підтримка мов БД
    | | 27 |

    2. Типова організація сучасної СУБД
    | | 29 |


    3. Ранні підходи до організації БД. Системи, засновані на інвертований списках, ієрархічні і мережні СУБД. Приклади. Сильні місця і недоліки ранніх систем
    | | 31 |

    1. Основні особливості систем, заснованих на інвертований списках
    | | 33 |

    1. Структури даних
    | | 33 |

    2. Маніпулювання даними
    | | 34 |

    3. Обмеження цілісності
    | | 35 |

    2. Ієрархічні системи
    | | 35 |

    1. Ієрархічні структури даних
    | | 35 |

    2. Маніпулювання даними
    | | 37 |

    3. Обмеження цілісності
    | | 37 |
    | 3.3. Мережеві системи | 38 |
    | 3.3.1. Мережеві структури даних | 38 |

    3. Маніпулювання даними
    | | 40 |

    4. Обмеження цілісності
    | | 41 |


    4. Переваги і недоліки
    | | 41 |


    5. Теоретичні основи
    | | 41 |


    6. Загальні поняття реляційного підходу до організації БД. Основні концепції та терміни
    | | 43 |

    1. Базові поняття реляційних баз даних
    | | 44 |

    1. Тип даних
    | | 44 |

    2. Домен
    | | 45 |

    3. Схема відносини, схема бази даних
    | | 45 |

    4. Кортеж, ставлення
    | | 46 |


    7. Методи використані для вирішення завдання.
    | | 48 |


    8. Відкрита архітектура Delphi
    | | 48 |


    9. Отримані результати
    | | 56 |
    | Модуль «Адміністратор програми« ОРІТН в порядку »» | 58 |
    | Висновок | 62 |


    10. Література
    | | 63 |
    | 12. Додаток 1 «Завдання на дипломне проектування» | 64 |
    | 13. Додаток 2 Вихідні тексти програми Модуль «Адміністратор | 65 |
    | програми «ОРІТН в порядку» »| |

    Введення

    відділення реанімації новонароджених вже протягом семи років займаєтьсяпорятунком життів ще не пізнали самого життя немовлят. Демографічнаситуація нашого регіону досить благополучна. Народжуваність рік від рокуне тільки не падає а ще й зростає, але важкі умови крайньої півночі іпостійно погіршуються умови навколишнього середовища вносять свої корективи вповноцінність підростаючого покоління. За період з 1991 року кількістьщо надходять у відділення щорічно дітей зросла майже в два рази,відповідно зріс і потік інформації необхідної для створення та аналізустатистичних звітів. До останнього часу введення і аналіз данихпроводився практично вручну, що називається на пальцях. Чи неіснувало єдиного стандарту на звіти, що ускладнювало аналіз данихнеобхідних для прийняття правильних рішень у виборі методів лікування.
    Сургутської відділення ОРІТН на сьогоднішній день є кращим по Росії,що дозволило прийняти його "столицею" в даній галузі медицини. З цього навідділення покладено обов'язок по стандартизації вихідних даних ізвітів. З 1996 року в Сургуті функціонує окружний навчально -консультативний центр на базі відділення ОРІТН МДБ № 1. Основним завданнямцентру є підвищення кваліфікації лікарів та консультативно-методичнадопомогу. Створення на основі мережі Інтернет статистичного сервера в місті
    Сургуті на який буде стікатися інформація з усього регіону, дозволитьцентру практично блискавично вирішити будь-яку проблему, з якою до ньогозвертаються лікарі з усього регіону. За основу даної системи буде взятамодель АСУ побудована нами в ході дипломного проектування.

    Постановка завдання.

    Розробка моделі АСУ ОРІТН. Реалізація моделі АСУ ОРІТН на мові Delphiкорпорації Inprise. Впровадження програмного продукту.

    Основи сучасних баз даних

    Бази даних і файлові системи
    Розглянемо загальний зміст понять БД і СУБД. Почнемо з того, що з самогопочатку розвитку обчислювальної техніки утворилися два основнінапрямки її використання. Перший напрямок - застосуванняобчислювальної техніки для виконання чисельних розрахунків, які занадтодовго або взагалі неможливо робити вручну. Становлення цьогонапрямку сприяло інтенсифікації методів чисельного рішенняскладних математичних задач, розвитку класу мов програмування,орієнтованих на зручний запис чисельних алгоритмів, становленнюзворотного зв'язку з розробниками нових архітектур ЕОМ.
    Другий напрямок, яке безпосередньо стосується теми нашого дипломногопроекту, це використання засобів обчислювальної техніки в автоматичнихабо автоматизованих інформаційних системах. У самому широкому сенсіінформаційна система являє собою програмний комплекс, функціїякого полягають у підтримці надійного зберігання інформації в пам'ятікомп'ютера, виконання специфічних для даного застосування перетвореньінформації та/або обчислень, надання користувачам зручного і легкоосвоюваної інтерфейсу. Зазвичай обсяги інформації, з якими доводитьсямати справу таких систем, досить великі, а сама інформація маєдосить складну структуру. Класичними прикладами інформаційних системє банківські системи, системи резервування авіаційних абозалізничних квитків, місць у готелях і т.д. Не є виняткомі розроблена нами система «ОРІТН».
    Насправді, другий напрямок виникло декілька пізніше першого. Цепов'язано з тим, що на зорі обчислювальної техніки комп'ютери володілиобмеженими можливостями в частині пам'яті. Зрозуміло, що можна говорити пронадійному і довгостроковому зберіганні інформації тільки при наявностізапам'ятовуючих пристроїв, що зберігають інформацію після вимкненняелектричного живлення. Оперативна пам'ять цією властивістю зазвичай неволодіє. На початку використовувалися два види пристроїв зовнішньої пам'яті:магнітні стрічки і барабани. При цьому ємність магнітних стрічок була доситьвелика, але за своєю фізичною природою вони забезпечували послідовнийдоступ до даних. Магнітні ж барабани (вони найбільше схожі насучасні магнітні диски з фіксованими головками) давали можливістьдовільного доступу до даними, але були обмеженого розміру.
    Легко бачити, що зазначені обмеження не дуже істотні для чисточисельних розрахунків. Навіть якщо програма повинна обробити (або зробити)великий обсяг інформації, при програмуванні можна продумати розташуванняцієї інформації у зовнішній пам'яті, щоб програма працювала як можнашвидше.
    З іншого боку, для інформаційних систем, у яких потреба впоточних даних визначається користувачем, наявність тільки магнітних стрічок ібарабанів незадовільно. Уявіть собі покупця квитка, якийстоячи біля каси повинен дочекатися повної перемотування магнітної стрічки. Одним зприродних вимог до таких систем є середня швидкістьвиконання операцій.
    Як здається, саме вимоги до обчислювальної техніки з боку нечисленних додатків викликали появу знімних магнітних дисків зрухомими головками, що стало революцією в історії обчислювальноїтехніки. Ці пристрої зовнішньої пам'яті мали істотно більшоюємністю, ніж магнітні барабани, забезпечували задовільну швидкістьдоступу до даних у режимі довільної вибірки, а можливість змінидискового пакета на пристрої дозволяла мати практично необмеженийархів даних.
    З появою магнітних дисків почалася історія систем управління даними узовнішньої пам'яті. До цього кожна прикладна програма, якою було потрібнозберігати дані у зовнішній пам'яті, сама визначала розташування кожноїпорції даних на магнітній стрічці або барабані і виконувала обміни міжоперативної і зовнішньої пам'яттю з допомогою програмно-апаратних засобівнизького рівня (машинних команд чи викликів відповідних програмопераційної системи). Такий режим роботи не дозволяє або дуже ускладнюєпідтримка на одному зовнішньому носії декількох архівів довготривалозбереженої інформації. Крім того, кожній прикладній програмі доводилосявирішувати проблеми іменування частин даних і структуризації даних у зовнішнійпам'яті.

    1.1. Файлові системи
    Історичним кроком був перехід до використання централізованих системуправління файлами. З точки зору прикладної програми файл - цеіменована область зовнішньої пам'яті, в яку можна записувати і з якоїможна зчитувати дані. Правила найменування файлів, спосіб доступу до даних,що зберігається у файлі, і структура цих даних залежать від конкретної системиуправління файлами і, можливо, від типу файлу. Система управління файламибере на себе розподіл зовнішньої пам'яті, відображення імен файлів увідповідні адреси в зовнішній пам'яті та забезпечення доступу до даних.
    Перша розвинена файлова система була розроблена фірмою IBM для її серії
    360. До теперішнього часу вона дуже застаріла, і ми не будемо розглядатиїї докладно. Зауважимо лише, що в цій системі підтримувалися як чистопослідовні, так і індексного-послідовні файли, а реалізація ув чому спиралася на можливості тільки що з'явилися до цього часуконтролерів керування дисковими пристроями. Якщо врахувати до того ж, щопоняття файлу в OS/360 було обрано як основне абстрактне поняття,якому відповідав будь-який зовнішній об'єкт, включаючи зовнішні пристрої,то працювати з файлами на рівні користувача було дуже незручно.
    Був потрібен цілий ряд громіздких і перевантажених деталями конструкцій. Всіце добре знайоме програмістам середнього та старшого покоління, якіпройшли через використання вітчизняних аналогів комп'ютерів IBM.

    1.1.1. Структури файлів
    Далі ми будемо говорити про більш сучасних організаціях файлових систем.
    Почнемо зі структур файлів. Перш за все, практично в усіх сучаснихкомп'ютерах основними пристроями зовнішньої пам'яті є магнітні дискиз рухомими головками, і саме вони служать для зберігання файлів. Такімагнітні диски представляють собою пакети магнітних пластин (поверхонь),між якими на одному важелі рухається пакет магнітних головок. Крокруху пакета головок є дискретним, і кожному положенню пакетуголовок логічно відповідає циліндр магнітного диска. На кожнійповерхні циліндр "висікає" доріжку, так що кожна поверхню міститьчисло доріжок, яка дорівнює кількості циліндрів. При розмітці магнітного диска
    (спеціальному дії, що передує використання диска) кожна доріжкарозмічається на одну й ту ж кількість блоків таким чином, що в кожнийблок можна записати по максимуму одне й те саме число байтів. Таким чином,для твори обміну з магнітним диском на рівні апаратури потрібновказати номер циліндра, номер поверхні, номер блоку на відповіднійдоріжці і число байтів, що треба записати або прочитати від початкуцього блоку.
    Однак ця можливість обмінюватися з магнітними дисками порціями меншеобсягу блоку в даний час не використовується в файлових системах. Цепов'язано з двома обставинами. По-перше, при виконанні обміну з дискомапаратура виконує три основні дії: підведення головок до потрібногоциліндра, пошук на доріжці потрібного блоку та власне обмін з цим блоком.
    З усіх цих дій в середньому найбільший час займає перше. Томуістотний виграш в сумарному часу обміну за рахунок зчитування абозапису тільки частини блоку отримати практично неможливо. По-друге,для того, щоб працювати з частинами блоків, файлова система повинназабезпечити відповідного розміру буфера оперативної пам'яті, щоістотно ускладнює розподіл оперативної пам'яті.
    Тому у всіх файлових системах явно чи неявно виділяється деякийбазовий рівень, що забезпечує роботу з файлами, що представляють набірпрямо адресуються в адресному просторі файлу блоків. Розмір цихлогічних блоків файлу збігається або кратний розміру фізичного блокудиска і зазвичай вибирається рівним розміру сторінки віртуальної пам'яті,підтримуваної апаратурою комп'ютера разом з операційною системою.
    У деяких файлових системах базовий рівень доступний користувачеві, алебільш часто прикривається деякими більш високим рівнем, стандартним длякористувачів. Поширені два основні підходи. При першому підході,властивому, наприклад, файлових систем операційних систем фірми DEC RSXі VMS, користувачі представляють файл як послідовність записів.
    Кожний запис - це послідовність байтів постійного або змінногорозміру. Записи можна читати або записувати послідовно абопозиціонувати файл на запис з вказаним номером. Деякі файловісистеми дозволяють структурувати запису на поля і оголошувати деякі поляключами запису. У таких файлових системах можна зажадати вибірку записуз файлу за її заданому ключу. Природно, що в цьому випадку файловасистема підтримує в тому ж (або іншому, службовому) базове фотододаткові, невидимі користувачеві, службові структури даних.
    Поширені способи організації ключових файлів грунтуються натехніці кешування і B-дерев. Існують і багато ключові способиорганізації файлів.
    Другий підхід, який став поширеним разом з операційною системою
    UNIX, полягає в тому, що будь-який файл представляється як послідовністьбайтів. З файлу можна прочитати зазначене число байтів або починаючи з йогопочатку, або попередньо зробивши його позиціонування на байт звказаним номером. Аналогічно, можна записати вказане число байтів вкінець файлу, або попередньо зробивши позиціонування файлу. Зауважимо,що тим не менш прихованим від користувача, але існуючим у всіхрізновиди файлових систем ОС UNIX, є базове блочнеподання файлу.
    Звичайно, для обох підходів можна забезпечити набір перетворюють функцій,приводять подання файлу до деякого іншого виду. Прикладом томуслужить підтримання стандартної файлової середовища системи програмування намові Сі в середовищі операційних систем фірми DEC.

    1.1.2. Іменування файлів
    Зупинимося коротко на способах найменування файлів. Всі сучасні файловісистеми підтримують багаторівневе іменування файлів за рахунок підтримкиу зовнішній пам'яті додаткових файлів зі спеціальною структурою --каталогів. Кожен каталог містить імена каталогів та/або файлів,що містяться в даному каталозі. Таким чином, повне ім'я файлу складається зсписку імен каталогів плюс назва файлу в каталозі, безпосередньо міститьдане зображення. Різниця між способами найменування файлів в різних файловихсистемах полягає в тому, з чого починається цей ланцюжок імен.
    У цьому відношенні є два крайніх варіанти. У багатьох системахуправління файлами потрібно, щоб кожен архів файлів (повне дереводовідників) цілком розташовувався на одному дисковому пакеті (або логічномудиску, у розділі фізичного дискового пакета, що надається за допомогоюзасобів операційної системи як окремий диск). У цьому випадку повне ім'яфайла починається з імені дискового пристрою, на якому встановленовідповідний диск. Такий спосіб іменування використовується в файловихсистемах фірми DEC, дуже близько до цього знаходяться та файлові системиперсональних комп'ютерів. Можна назвати цю організацію підтриманнямізольованих файлових систем.
    Інший крайній варіант був реалізований в файлових системах операційноїсистеми Multics. Ця система заслуговує окремої великої розмови, вній був реалізований цілий ряд оригінальних ідей, але ми зупинимося лише наособливості організації архіву файлів. У файловій системі Milticsкористувачі представляли всю сукупність каталогів і файлів як єдинедерево. Повне ім'я файлу починалося з імені кореневого каталогу, ікористувач не зобов'язаний був піклуватися про встановлення на дисковий пристрійбудь-яких конкретних дисків. Сама система, виконуючи пошук файлу за йогоімені, запрошувала установку необхідних дисків. Таку файлову системуможна назвати повністю централізованою.
    Звичайно, багато в чому централізовані файлові системи зручніше ізольованих:система управління файлами бере на себе більше рутинної роботи. Але втаких системах виникають суттєві проблеми, якщо комусь потрібноперенести піддерево файлової системи на іншу обчислювальну установку.
    Компромісне рішення застосоване в файлових системах ОС UNIX. На базовомурівні в цих файлових системах підтримуються ізольовані архіви файлів.
    Один з цих архівів оголошується кореневою файловою системою. Після запускусистеми можна "змонтувати" кореневу файлову систему і ряд ізольованихфайлових систем в одну загальну файлову систему. Технічно це здійснюєтьсяза допомогою заклади в кореневій файловій системі спеціальних порожніхкаталогів. Спеціальний системний виклик кур'єр ОС UNIX дозволяє підключитидо одного з цих порожніх каталогів кореневий каталог зазначеного архівуфайлів. Після монтування загальної файлової системи іменування файлівпроводиться так само, як якщо б вона з самого початку була централізованою.
    Якщо врахувати, що зазвичай монтування файлової системи здійснюється прирозкручуванні системи, то користувачі ОС UNIX зазвичай і не замислюються провихідному походження загальної файлової системи.

    1.1.3. Захист файлів
    Оскільки файлові системи є загальним сховищем файлів, що належать,взагалі кажучи, різним користувачам, системи управління файлами повиннізабезпечувати авторизацію доступу до файлів. У загальному вигляді підхід полягає вте, що по відношенню до кожному зареєстрованому користувачеві даноїобчислювальної системи для кожного існуючого файлу вказуютьсядії, які дозволені або заборонені даному користувачеві.
    Існували спроби реалізувати цей підхід у повному обсязі. Але цевикликало дуже великі накладні витрати як зі зберігання надлишковоїінформації, так і з використання цієї інформації для контролюправомочності доступу.
    Тому в більшості сучасних систем управління файлами застосовуєтьсяпідхід до захисту файлів, вперше реалізований в ОС UNIX. У цій системікожному зареєстрованому користувачеві відповідає пара цілочисельнихідентифікаторів: ідентифікатор групи, до якої належить цейкористувач, і його власний ідентифікатор в групі. Відповідно, прикожен файл зберігається повний ідентифікатор користувача, який створивце фото, і зазначається, які дії з файлом може виробляти він сам,які дії з файлом доступні для інших користувачів тієї ж групи, іщо можуть робити з файлом користувачі інших груп. Ця інформація дужекомпактна, при перевірці потрібна невелика кількість дій, і цейспосіб контролю доступу задовільний в більшості випадків.

    1.1.4. Режим багатокористувацького доступу
    Останнє, на чому ми зупинимося у зв'язку з файлами, - це способи їхвикористання в багатокористувацької середовищі. Якщо операційна системапідтримує багатокористувацький режим, цілком реальна ситуація, колидві або більше користувачів одночасно намагаються працювати з одним і тим жефайлом. Якщо всі ці користувачі збираються тільки читати файл, нічогострашного не відбудеться. Але якщо хоча б одна з них буде змінювати файл,для коректної роботи цієї групи потрібна взаємна синхронізація.
    Історично в файлових системах застосовувався наступний підхід. В операціївідкриття файлу (перша та обов'язкової операції, з якої має починатисясеанс роботи з файлом) крім інших параметрів вказувався режим роботи
    (читання або зміна). Якщо до моменту виконання цієї операції від іменідеякої програми A файл вже знаходився у відкритому стані від іменідеякої іншої програми B (правильніше говорити "процесу", але ми небудемо вдаватися в термінологічні тонкощі), причому існуючий режимвідкриття був несумісним з бажаним режимом (сумісні тільки режимичитання), то в залежності від особливостей системи програмі A абоповідомлялося про неможливість відкриття файлу в бажаному режимі, або вонаблокувалася до тих пір, поки програма B не виконає операцію закриттяфайлу.
    Зауважимо, що в ранніх версіях файлової системи ОС UNIX взагалі не булиреалізовані які б то не було засоби синхронізації паралельногодоступу до файлів. Операція відкриття файлу виконувалася завжди для будь-якогоіснуючого файлу, якщо цей користувач мав відповідні правадоступу. При спільній роботі синхронізацію слід було проводити позафайлової системи (і особливих засобів для цього ОС UNIX не надавала). Усучасних реалізаціях файлових систем ОС UNIX за бажанням користувачапідтримується синхронізація при відкритті файлів. Крім того, існуєможливість синхронізації декількох процесів, паралельно модифікуючиходин і той же файл. Для цього введено спеціальний механізм синхронізаційнихзахоплень діапазонів адрес відкритого файлу.

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

    1.3. Потреби інформаційних систем
    Однак ситуація докорінно відрізняється для згадуваних на початкулекції інформаційних систем. Ці системи головним чином орієнтовані назберігання, вибір і модифікацію постійно існуючої інформації. Структураінформації часто дуже складна, і хоча структури даних різні в різнихінформаційних системах, між ними часто буває багато спільного. На початковомуетапі використання обчислювальної техніки для управління інформацієюпроблеми структуризації даних вирішувалися індивідуально в кожнійінформаційній системі. Проводилися необхідні надбудови над файловимисистемами (бібліотеки програм), подібно до того, як це робиться вкомпіляторах, редакторів і т.д.
    Але оскільки інформаційні системи вимагають складних структур даних, цідодаткові індивідуальні засоби керування даними булиістотною частиною інформаційних систем і практично повторювалися відоднієї системи до іншої. Прагнення виділити і узагальнити спільну частинуінформаційних систем, відповідальну за управління складноструктурованими даними, стало, на наш погляд, перший спонукальноїпричиною створення СУБД. Дуже скоро стало зрозуміло, що неможливо обійтисязагальною бібліотекою програм, що реалізує над стандартної базової файловоїсистемою більш складні методи зберігання даних.
    Покажемо це на прикладі. Припустимо, що ми хочемо реалізувати простуінформаційну систему, яка підтримує облік співробітників деякоїорганізації. Система повинна виконувати наступні дії: видавати спискиспівробітників по відділах, підтримувати можливість переведення співробітника зодного відділу в інший, прийому на роботу нових співробітників і звільненняпрацюючих. Для кожного відділу має підтримуватися можливість отриманняімені керівника цього відділу, загальної чисельності відділу, загальної сумивиплаченої в останній раз зарплати і т.д. Для кожного співробітника маєпідтримуватися можливість видачі номера посвідчення по повному іменіспівробітника, видачі повного імені за номером посвідчення, отриманняінформації про поточний відповідність займаній посаді співробітника і пророзмірі його зарплати.
    Припустимо, що ми вирішили засновувати цю інформаційну систему нафайлової системи і користуватися при цьому одним файлом, розширивши базовіможливості файлової системи за рахунок спеціальної бібліотеки функцій.
    Оскільки мінімальної інформаційної одиницею у нашому випадку єспівробітник, природно вимагати, щоб в цьому файлі містилася одназапис для кожного співробітника. Які поля повинна містити такий запис?
    Повне ім'я співробітника (СОТР_ІМЯ), номер його посвідчення (СОТР_НОМЕР),інформацію про його відповідність займаній посаді (для простоти, "так" або
    "ні") (СОТР_СТАТ), розмір зарплати (СОТР_ЗАРП), номер відділу
    (СОТР_ОТД_НОМЕР). Оскільки ми хочемо обмежитися одним файлом, та жзапис має містити ім'я керівника відділу (СОТР_ОТД_РУК).
    Функції нашої інформаційної системи вимагають, щоб забезпечуваласяможливість багато ключового доступу до цього файлу по унікальних ключів (недубльованих в різних записах) СОТР_ІМЯ і СОТР_НОМЕР. Крім того, повинназабезпечуватися можливість вибору всіх записів з Загалом значенням
    СОТР_ОТД_НОМЕР, тобто доступ по неунікальному ключу. Для того, щоботримати чисельність відділу або загальний розмір зарплати, кожного разу привиконання такої функції інформаційна система повинна буде вибрати всізаписи про співробітників відділу і порахувати відповідні загальні значення.
    Таким чином ми бачимо, що навіть для такої простої системи її реалізація набазі файлової системи, по-перше, вимагає створення досить складноїнадбудови для багато ключового доступу до файлів, і, по-друге, викликаєвимога істотної надмірності зберігання (для кожного співробітникаодного відділу повторюється ім'я керівника) і виконання масової вибірки іобчислень для отримання сумарної інформації про відділи. Крім того, якщов ході експлуатації системи нам захочеться, наприклад, видавати спискиспівробітників, що одержують задану зарплату, то доведеться або повністюпереглядати файл, або реструктурізовивать його, оголошуючи ключовим поле
    СОТР_ЗАРП.
    Перше, що спадає на думку, - це підтримувати два багато ключових файлу:
    СПІВРОБІТНИКИ і ВІДДІЛИ. Перший файл повинен містити поля СОТР_ІМЯ,
    СОТР_НОМЕР, СОТР_СТАТ, СОТР_ЗАРП і СОТР_ОТД_НОМЕР, а другий - ОТД_НОМЕР,
    ОТД_РУК, ОТД_СОТР_ЗАРП (загальний розмір зарплати) і ОТД_РАЗМЕР (загальне числоспівробітників у відділі). Більшість незручностей, перелічених у попередньомуабзаці, будуть подолані. Кожен з файлів буде містити тільки недубльованих інформацію, потреби в динамічних обчисленнях сумарноюінформації не виникає. Але зауважимо, що при такому переході нашаінформаційна система повинна володіти деякими новими особливостями,зближують її з СУБД.
    Перш за все, система повинна тепер знати, що вона працює з двомаінформаційно пов'язаними файлами (це крок у бік схеми бази даних),повинна знати структуру та зміст кожного поля (наприклад, що СОТР_ОТД_НОМЕР вфото СПІВРОБІТНИКИ і ОТД_НОМЕР у файлі ВІДДІЛИ означають одне й те саме), а такожрозуміти, що в ряді випадків зміна інформації в одному файлі маєавтоматично викликати модифікацію в другому файлі, щоб їх загальневміст було узгодженим. Наприклад, якщо на роботу приймається новийспівробітник, то необхідно додати запис в файл СПІВРОБІТНИКИ, а такожвідповідним чином змінити поля ОТД_ЗАРП і ОТД_РАЗМЕР в запису файлу
    ВІДДІЛИ, яка описує відділ цього співробітника.
    Поняття узгодженості даних є ключовим поняттям баз даних.
    Фактично, якщо інформаційна система (навіть така проста, як у нашомуприкладі) підтримує узгоджене зберігання інформації в декількохфайлах, можна говорити про те, що вона підтримує базу даних. Якщо ждеяка допоміжна система керування даними дозволяє працювати здекількома файлами, забезпечуючи їх узгодженість, можна назвати їїсистемою керування базами даних. Вже тільки вимога підтримкиузгодженості даних в декількох файлах не дозволяє обійтисябібліотекою функцій: така система повинна мати деякі власніРозташування (метадані) і навіть знання, що визначають цілісність даних.
    Але це ще не все, що зазвичай вимагають від СУБД. По-перше, навіть у нашомуприкладі незручно реалізовувати такі запити як "видати загальну чисельністьвідділу, в якому працює Петро Іванович Сидоров ". Було б набагато простіше,якби СУБД дозволяла сформулювати такий запит на близькій користувачаммовою. Такі мови називаються мовами запитів до баз даних. Наприклад, намовою SQL наш запит можна було б виразити у формі:
    SELECT ОТД_РАЗМЕР
    FROM СПІВРОБІТНИКИ, ВІДДІЛИ
    WHERE СОТР_ІМЯ = "ПЕТРО ІВАНОВИЧ СИДОРОВ"
    AND СОТР_ОТД_НОМЕР = ОТД_НОМЕР
    Таким чином, при формулюванні запиту СУБД дозволить не замислюватися проте, як буде виконуватися цей запит. Серед її метаданих будеміститися інформація про те, що поле СОТР_ІМЯ є ключовим для файлу
    СПІВРОБІТНИКИ, а ОТД_НОМЕР - для файла ВІДДІЛИ, і система сама скористаєтьсяцим. Якщо ж виникне потреба в отриманні списку співробітників, невідповідних займаної посади, то достатньо пред'явити системізапит
    SELECT СОТР_ІМЯ, СОТР_НОМЕР
    FROM СПІВРОБІТНИКИ
    WHERE СОТР_СТАТ = "НІ",і система сама виконає необхідний повний перегляд файлу СПІВРОБІТНИКИ,оскільки поле СОТР_СТАТ не є ключовим.
    Далі, уявіть собі, що в нашій первісної реалізаціїінформаційної системи, заснованої на використанні бібліотек розширенихметодів доступу до файлів, обробляється операція реєстрації новогоспівробітника. Слідуючи вимогам узгодженого зміни файлів,інформаційна система вставила новий запис у файл СПІВРОБІТНИКИ і збираласямодифіковані запис файла ВІДДІЛИ, але саме в цей момент відбулосяаварійне вимикання живлення. Очевидно, що після перезапуску системи їїбаза даних буде знаходитися в рассогласованном стані. Буде потрібноз'ясувати це (а для цього потрібно явно перевірити відповідність інформації зфайлах СПІВРОБІТНИКИ і ВІДДІЛИ) і привести інформацію в узгодженийстан. Справжні СУБД беруть таку роботу на себе. Прикладна система незобов'язана піклуватися про коректність стану бази даних.
    Нарешті, уявимо собі, що ми хочемо забезпечити паралельну (наприклад,багатотермінальних) роботу з базою даних співробітників. Якщо спиратися тількина використання файлів, то для забезпечення коректності на весь часмодифікації будь-якого з двох файлів доступ інших користувачів до цього файлубуде блокований (згадайте можливості файлових систем для синхронізаціїпаралельного доступу). Таким чином, зарахування на роботу Петра Івановича
    Сидорова істотно загальмує отримання інформації про співробітника Івана
    Сидорович Петрове, навіть якщо вони будуть працювати в різних відділах.
    Справжні СУБД забезпечують набагато більш тонку синхронізаціюпаралельного доступу до даних.
    Таким чином, СУБД вирішують безліч проблем, які важко абовзагалі неможливо вирішити при використанні файлових систем. При цьомуіснують програми, для яких цілком достатньо файлів; додатки,для яких необхідно вирішувати, який рівень роботи з данимими в зовнішнійпам'яті для них потрібна, і додатки, для яких безумовно потрібні базиданих.

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

    2.1. Основні функції СУБД
    Більш точно, до числа функцій СУБД прийнято відносити наступні:

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

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

    2.1.3. Управління транзакціями
    Транзакція - це послідовність операцій над БД, що розглядаються СУБДяк єдине ціле. Або транзакція успішно виконується, і СУБД фі

         
     
         
    Реферат Банк
     
    Рефераты
     
    Бесплатные рефераты
     

     

     

     

     

     

     

     
     
     
      Все права защищены. Reff.net.ua - українські реферати ! DMCA.com Protection Status