Диплом: Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии новорожденных МГБ N1 г. Сургута - текст диплома. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Диплом

Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии новорожденных МГБ N1 г. Сургута

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Дипломная работа
Язык диплома: Русский
Дата добавления:   
 
Скачать
Архив Zip, 1412 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникальной дипломной работы

Узнайте стоимость написания уникальной работы

86 Министерство общего и профессионального образования РФ Сургутский го сударственный университет Факультет информационных технологий Кафедра информатики и вычислительной техники Дипломная работа На тему «Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии Новорожденных при Муниципальной Гор одской Больнице № 1 города Сургута» Выполнил : Юрий В . Гудонис Руководитель : Челноков С . Б. Рецензент : Шепелев А.С. Сургут 1998г. Содержание Введение 4 Постановка задачи 5 Основы современных баз данных 6 1. Базы данных и файловые системы 6 1.1. Файловые с и стемы 8 1.1.1. Структуры файлов 9 1.1.2. Именование файлов 11 1.1.3. Защита файлов 13 1.1.4. Режим многопользовательского доступа 14 1.2. Области применения файлов 15 1.3. Потребности информационны х систем 16 2. Функции СУБД . Типовая организация СУБД . Примеры 21 2.1. Основные функции СУБД 22 2.1.1. Непосредственное управление данными во внешней памяти 22 2.1.2. Управление буферами оперативной памяти 22 2.1.3. Управление транзакциями 23 2.1.4. Журнализация 24 2.1.5. Поддержка языков БД 27 2.2. Типовая организация современной СУБД 29 3. Ранние подходы к организации БД . Системы , основанные на инвертированных списках , иерархические и сетевые СУБД . Примеры . Сильные места и недостатки ра нних систем 31 3.1. Основные особенности систем , основанных на инвертированных списках 33 3.1.1. Структуры данных 33 3.1.2. Манипулирование данными 34 3.1.3. Ограничения целостности 35 3.2. Иерархические системы 35 3.2.1. Иерархические структур ы данных 35 3.2.2. Манипулирование данными 37 3.2.3. Ограничения целостности 37 3.3. Сетевые системы 38 3.3.1. Сетевые структуры данных 38 3.3.2. Манипулирование данными 40 3.3.3. Ограничения целостности 41 3.3.4. Достоинства и недостатки 41 Теоретические основы 41 4. Общие понятия реляционного подхода к организации БД . Основные концепции и термины 43 4.1. Базовые понятия реляционных баз данных 44 4.1.1. Тип данных 44 4.1.2. Домен 45 4.1.3. Схема отношения , схема базы данных 45 4.1.4. Кортеж , отношение 46 5. Методы использованные для решения задачи. 48 6. Открытая архитектура Delphi 48 7. Полученные результаты 56 8. Модуль «Администратор программы «ОРИТН в порядке»» 58 9. Заключение 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. Управление транзакциями Транзакция - это последовательность операций над БД , рассматриваемых СУБД как единое целое . Либо транзакция успешно выполняется , и СУБД фиксирует (COMMIT) изменения БД , произведенные этой транзакцией , во внешней памяти , либо ни одно из этих изменений никак не отражается на состоянии БД . По н ятие транзакции необходимо для поддержания логической целостности БД . Если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ , то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотру д ника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию . Таким образом , поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если , конечно , такая система заслуживает назв а ния СУБД ). Но понятие транзакции гораздо более важно в многопользовательских СУБД . То свойство , что каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения , делает очень удобным использование пон ятия транзакции как единицы активности пользователя по отношению к БД . При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД (на самом д е ле , это несколько идеализированное представление , поскольку в некоторых случаях пользователи многопользовательских СУБД могут ощутить присутствие своих коллег ). С управлением транзакциями в многопользовательской СУБД связаны важные понятия сериализации тр анзакций и сериального плана выполнения смеси транзакций. Под сериализаций параллельно выполняющихся транзакций понимается такой порядок планирования их работы , при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательн ого выполнения . Сериальный план выполнения смеси транзакций - это такой план , который приводит к сериализации транзакций . Понятно , что если удается добиться действительно сериального выполнения смеси транзакций , то для каждого пользователя , по инициативе к оторого образована транзакция , присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом ). Существует несколько базовых алгоритмов сериализации транзакций . В централизованных СУ БД наиболее распространены алгоритмы , основанные на синхронизационных захватах объектов БД . При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД . В этом случае для поддерж а ния сериализации необходимо выполнить откат (ликвидировать все изменения , произведенные в БД ) одной или более транзакций . Это один из случаев , когда пользователь многопользовательской СУБД может реально (и достаточно неприятно ) ощутить присутствие в систе м е транзакций других пользователей . 2.1.4. Журнализация Одним из основных требований к СУБД является надежность хранения данных во внешней памяти . Под надежностью хранения понимается то , что СУБД должна быть в состоянии восстановить последнее согласованно е состояние БД после любого аппаратного или программного сбоя . Обычно рассматриваются два возможных вида аппаратных сбоев : так называемые мягкие сбои , которые можно трактовать как внезапную остановку работы компьютера (например , аварийное выключение питан и я ), и жесткие сбои , характеризуемые потерей информации на носителях внешней памяти . Примерами программных сбоев могут быть : аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя ) или аварийное заверше н ие пользовательской программы , в результате чего некоторая транзакция остается незавершенной . Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя ; при возникновении последней требуется ликвидировать последствия только одной транзак ц ии . Понятно , что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией . Другими словами , поддержание надежности хранения данных в БД требует избыточности хранения данных , причем та часть данных , которая используется д ля восстановления , должна храниться особо надежно . Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД . Журнал - это особая часть БД , недоступная пользователям СУБД и поддерживаемая с особой тщат ельностью (иногда поддерживаются две копии журнала , располагаемые на разных физических дисках ), в которую поступают записи обо всех изменениях основной части БД . В разных СУБД изменения БД журнализуются на разных уровнях : иногда запись в журнале соответст в ует некоторой логической операции изменения БД (например , операции удаления строки из таблицы реляционной БД ), иногда - минимальной внутренней операции модификации страницы внешней памяти ; в некоторых системах одновременно используются оба подхода . Во все х случаях придерживаются стратегии "упреждающей " записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря , эта стратегия заключается в том , что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше , ч е м измененный объект попадет во внешнюю память основной части БД . Известно , что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя . Самая простая ситуация восстановления - инди видуальный откат транзакции . Строго говоря , для этого не требуется общесистемный журнал изменений БД . Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД , выполненных в этой транзакции , и производить откат транзакции пут е м выполнения обратных операций , следуя от конца локального журнала . В некоторых СУБД так и делают , но в большинстве систем локальные журналы не поддерживают , а индивидуальный откат транзакции выполняют по общесистемному журналу , для чего все записи от одн о й транзакции связывают обратным списком (от конца к началу ). При мягком сбое во внешней памяти основной части БД могут находиться объекты , модифицированные транзакциями , не закончившимися к моменту сбоя , и могут отсутствовать объекты , модифицированные тра нзакциями , которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти , содержимое которых при мягком сбое пропадает ). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи , отно с ящиеся к операциям модификации обоих видов объектов . Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД , которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций . Для того , чтобы этого добиться , сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций , результаты которых не отображены в о внешней памяти . Этот процесс содержит много тонкостей , связанных с общей организацией управления буферами и журналом . Более подробно мы рассмотрим это в соответствующей лекции . Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД . Грубо говоря , архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии ). Конечно , для нормального восстановления БД после жесткого сбоя необходимо , чтобы журнал не п р опал . Как уже отмечалось , к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования . Тогда восстановление БД состоит в том , что исходя из архивной копии по журналу воспроизводится работа всех транзакций , которые закончились к моменту сбоя . В принципе , можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления . Однако в реальных системах это обычно не делается , поскольку процесс восстановления после жесткого сбоя является до с таточно длительным . 2.1.5. Поддержка языков БД Для работы с базами данных используются специальные языки , в целом называемые языками баз данных . В ранних СУБД поддерживалось несколько специализированных по своим функциям языков . Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД , т.е . той структуры БД , какой она представляется пол ьзователям . DML содержал набор операторов манипулирования данными , т.е . операторов , позволяющих заносить данные в БД , удалять , модифицировать или выбирать существующие данные . Мы рассмотрим более подробно языки ранних СУБД в следующей лекции . В современны х СУБД обычно поддерживается единый интегрированный язык , содержащий все необходимые средства для работы с БД , начиная от ее создания , и обеспечивающий базовый пользовательский интерфейс с базами данных . Стандартным языком наиболее распространенных в наст о ящее время реляционных СУБД является язык SQL (Structured Query Language). В нескольких лекциях этого курса язык SQL будет рассматриваться достаточно подробно , а пока мы перечислим основные функции реляционной СУБД , поддерживаемые на "языковом " уровне (т. е . функции , поддерживаемые при реализации интерфейса SQL). Прежде всего , язык SQL сочетает средства SDL и DML, т.е . позволяет определять схему реляционной БД и манипулировать данными . При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов ) поддерживается на языковом уровне в том смысле , что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов . Внутренняя часть СУБД (ядро ) в ообще не работает с именами таблиц и их столбцов . Язык SQL содержит специальные средства определения ограничений целостности БД . Опять же , ограничения целостности хранятся в специальных таблицах-каталогах , и обеспечение контроля целостности БД производитс я на языковом уровне , т.е . при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код . Специальные операторы языка SQL позволяют определять так называемые представ ления БД , фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица ) с именованными столбцами . Для пользователя представление является такой же таблицей , как любая базовая таблица , хранимая в БД , но с пом о щью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя . Поддержание представлений производится также на языковом уровне . Наконец , авторизация доступа к объектам БД производится также на основе специального набо ра операторов SQL. Идея состоит в том , что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями . Пользователь , создавший таблицу БД , обладает полным набором полномочий для работы с этой таблицей . В число этих пол н омочий входит полномочие на передачу всех или части полномочий другим пользователям , включая полномочие на передачу полномочий . Полномочия пользователей описываются в специальных таблицах-каталогах , контроль полномочий поддерживается на языковом уровне . Б олее точное описание возможных реализаций этих функций на основе языка SQL будет приведено в лекциях , посвященных языку SQL и его реализации . 2.2. Типовая организация современной СУБД Естественно , организация типичной СУБД и состав ее компонентов соответ ствует рассмотренному нами набору функций . Напомним , что мы выделили следующие основные функции СУБД : · управление данными во внешней памяти ; · управление буферами оперативной памяти ; · управление транзакциями ; · журнализация и восстановление БД по сле сбоев ; · поддержание языков БД . Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения , набор ути лит . В некоторых системах эти части выделяются явно , в других - нет , но логически такое разделение можно провести во всех СУБД . Ядро СУБД отвечает за управление данными во внешней памяти , управление буферами оперативной памяти , управление транзакциями и ж урнализацию . Соответственно , можно выделить такие компоненты ядра (по крайней мере , логически , хотя в некоторых системах эти компоненты выделяются явно ), как менеджер данных , менеджер буферов , менеджер транзакций и менеджер журнала . Как можно было понять и з первой части этой лекции , функции этих компонентов взаимосвязаны , и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам . Ядро СУБД обладает собственным интерфейсом , не дост у пным пользователям напрямую и используемым в программах , производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ ) и утилитах БД . Ядро СУБД является основной резидентной частью СУБД . При использовании архитектуры "клиент-сервер " ядро является основной составляющей серверной части системы . Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу . Основной проблемой реляционных СУБД является то , что языки этих систем (а это , к ак правило , SQL) являются непроцедурными , т.е . в операторе такого языка специфицируется некоторое действие над БД , но эта спецификация не является процедурой , а лишь описывает в некоторой форме условия совершения желаемого действия (вспомните примеры из п е рвой лекции ). Поэтому компилятор должен решить , каким образом выполнять оператор языка прежде , чем произвести программу . Применяются достаточно сложные методы оптимизации операторов , которые мы подробно рассмотрим в следующих лекциях . Результатом компиляц и и является выполняемая программа , представляемая в некоторых системах в машинных кодах , но более часто в выполняемом внутреннем машинно-независимом коде . В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки вре м ени выполнения , представляющей собой , по сути дела , интерпретатор этого внутреннего языка . Наконец , в отдельные утилиты БД обычно выделяют такие процедуры , которые слишком накладно выполнять с использованием языка БД , например , загрузка и выгрузка БД , сбо р статистики , глобальная проверка целостности БД и т.д . Утилиты программируются с использованием интерфейса ядра СУБД , а иногда даже с проникновением внутрь ядра . Ранние подходы к организации БД . Системы , основанные на инвертированных списках , иерархичес кие и сетевые СУБД . Примеры . Сильные места и недостатки ранних систем Прежде , чем перейти к детальному и последовательному изучению реляционных систем БД , остановимся коротко на ранних (дореляционных ) СУБД . В этом есть смысл по трем причинам : во-первых , эт и системы исторически предшествовали реляционным , и для правильного понимания причин повсеместного перехода к реляционным системам нужно знать хотя бы что-нибудь про их предшественников ; во-вторых , внутренняя организация реляционных систем во многом основ а на на использовании методов ранних систем ; в-третьих , некоторое знание в области ранних систем будет полезно для понимания путей развития пост реляционных СУБД . Заметим , что в этой лекции мы ограничиваемся рассмотрением только общих подходов к организации трех типов ранних систем , а именно , систем , основанных на инвертированных списках , иерархических и сетевых систем управления базами данных . Мы не будем касаться особенностей каких-либо конкретных систем ; это привело бы к изложению многих технических дета л ей , которые , хотя и интересны , находятся несколько в стороне от основной цели нашего курса . Детали можно найти в рекомендованной литературе . Начнем с некоторых наиболее общих характеристик ранних систем : a. Эти системы активно использовались в течение мн огих лет , дольше , чем используется какая-либо из реляционных СУБД . На самом деле некоторые из ранних систем используются даже в наше время , накоплены громадные базы данных , и одной из актуальных проблем информационных систем является использование этих си с тем совместно с современными системами . b. Все ранние системы не основывались на каких-либо абстрактных моделях . Как мы упоминали , понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом . Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем . c. В ранних системах доступ к БД производился на уровне записей . Пользователи этих систем осуществляли явную навигацию в БД , используя языки программирования , расширенные функциями СУБД . Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом . d. Можно считать , что уровень средств ранних СУБД соотносится с уровнем файло вых систем примерно так же , как уровень языка Кобол соотносится с уровнем языка Ассемблера . Заметим , что при таком взгляде уровень реляционных систем соответствует уровню языков Ада или APL. e. Навигационная природа ранних систем и доступ к данным на уров не записей заставляли пользователя самого производить всю оптимизацию доступа к БД , без какой-либо поддержки системы . f. После появления реляционных систем большинство ранних систем было оснащено "реляционными " интерфейсами . Однако в большинстве случаев э то не сделало их по-настоящему реляционными системами , поскольку оставалась возможность манипулировать данными в естественном для них режиме . 3.1. Основные особенности систем , основанных на инвертированных списках К числу наиболее известных и типичных пр едставителей таких систем относятся Datacom/DB компании Applied Data Research, Inc. (ADR), ориентированная на использование на машинах основного класса фирмы IBM, и Adabas компании Software AG . Организация доступа к данным на основе инвертированных списко в используется практически во всех современных реляционных СУБД , но в этих системах пользователи не имеют непосредственного доступа к инвертированным спискам (индексам ). Кстати , когда мы будем рассматривать внутренние интерфейсы реляционных СУБД , вы увиди т е , что они очень близки к пользовательским интерфейсам систем , основанных на инвертированных списках . 3.1.1. Структуры данных База данных , организованная с помощью инвертированных списков , похожа на реляционную БД , но с тем отличием , что хранимые таблицы и пути доступа к ним видны пользователям . При этом : a. Строки таблиц упорядочены системой в некоторой физической последовательности . b. Физическая упорядоченность строк всех таблиц может определяться и для всей БД (так делается , например , в Datacom/DB ). c. Для каждой таблицы можно определить произвольное число ключей поиска , для которых строятся индексы . Эти индексы автоматически поддерживаются системой , но явно видны пользователям . 3.1.2. Манипулирование данными Поддерживаются два класса операторов : a. Операторы , устанавливающие адрес записи , среди которых : · прямые поисковые операторы (например , найти первую запись таблицы по некоторому пути доступа ); · операторы , находящие запись в терминах относительной позиции от предыдущей записи по некоторо му пути доступа . Операторы над адресуемыми записями Типичный набор операторов : · LOCATE FIRST - найти первую запись таблицы T в физическом порядке ; возвращает адрес записи ; · LOCATE FIRST WITH SEARCH KEY EQUAL - найти первую запись таблицы T с заданн ым значением ключа поиска K; возвращает адрес записи ; · LOCATE NEXT - найти первую запись , следующую за записью с заданным адресом в заданном пути доступа ; возвращает адрес записи ; · LOCATE NEXT WITH SEARCH KEY EQUAL - найти следующую запись таблицы T в порядке пути поиска с заданным значением K; должно быть соответствие между используемым способом сканирования и ключом K; возвращает адрес записи ; · LOCATE FIRST WITH SEARCH KEY GREATER - найти первую запись таблицы T в порядке ключа поиска K cо значен ием ключевого поля , большим заданного значения K; возвращает адрес записи ; · RETRIVE - выбрать запись с указанным адресом ; · UPDATE - обновить запись с указанным адресом ; · DELETE - удалить запись с указанным адресом ; · STORE - включить запись в ук азанную таблицу ; операция генерирует адрес записи . 3.1.3. Ограничения целостности Общие правила определения целостности БД отсутствуют . В некоторых системах поддерживаются ограничения уникальности значений некоторых полей , но в основном все возлагается н а прикладную программу . 3.2. Иерархические системы Типичным представителем (наиболее известным и распространенным ) является Information Management System (IMS) фирмы IBM . Первая версия появилась в 1968 г . До сих пор поддерживается много баз данных , что с оздает существенные проблемы с переходом как на новую технологию БД , так и на новую технику . 3.2.1. Иерархические структуры данных Иерархическая БД состоит из упорядоченного набора деревьев ; более точно , из упорядоченного набора нескольких экземпляров од ного типа дерева . Тип дерева состоит из одного "корневого " типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева ). Тип дерева в целом представляет собой иерархически организованный набор типов записи . Пример типа дерева (схемы иерархической БД ): Здесь Отдел является предком для Начальник и Сотрудники , а Начальник и Сотрудники - потомки Отдел . Между типами записи поддерживаются связи . База данных с такой схемой могла бы выглядеть следующим образом (мы показываем один экземпляр дерева ): Все экземпляры данно го типа потомка с общим экземпляром типа предка называются близнецами . Для БД определен полный порядок обхода - сверху-вниз , слева-направо . В IMS использовалась оригинальная и нестандартная терминология : "сегмент " вместо "запись ", а под "записью БД " поним алось все дерево сегментов . 3.2.2. Манипулирование данными Примерами типичных операторов манипулирования иерархически организованными данными могут быть следующие : · Найти указанное дерево БД (например , отдел 310); · Перейти от одного дерева к другом у ; · Перейти от одной записи к другой внутри дерева (например , от отдела - к первому сотруднику ); · Перейти от одной записи к другой в порядке обхода иерархии ; · Вставить новую запись в указанную позицию ; · Удалить текущую запись . 3.2.3. Ограниче ния целостности Автоматически поддерживается целостность ссылок между предками и потомками . Основное правило : никакой потомок не может существовать без своего родителя . Заметим , что аналогичное поддержание целостности по ссылкам между записями , не входящим и в одну иерархию , не поддерживается (примером такой "внешней " ссылки может быть содержимое поля Каф _Номер в экземпляре типа записи Куратор ). В иерархических системах поддерживалась некоторая форма представлений БД на осн ове ограничения иерархии . Примером представления приведенной выше БД может быть иерархия 3.3. Сетевые системы Типичным представителем явл яется Integrated Database Management System (IDMS) компании Cullinet Software, Inc ., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем . Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации , ответственной за определение языка программирования Кобол . Отчет DBTG был опубликован в 1971 г ., а в 70-х годах появилось несколько сист ем , среди которых IDMS. 3.3.1. Сетевые структуры данных Сетевой подход к организации данных является расширением иерархического . В иерархических структурах запись-потомок должна иметь в точности одного предка ; в сетевой структуре данных потомок может име ть любое число предков . Сетевая БД состоит из набора записей и набора связей между этими записями , а если говорить более точно , из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного н абора типов связи . Тип связи определяется для двух типов записи : предка и потомка . Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка . Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия : · Каждый экземпляр типа P является предком только в одном экземпляре L; · Каждый экземпляр C является потомком не более , чем в одном экземпляре L. На формирование типов связи не нак ладываются особые ограничения ; возможны , например , следующие ситуации : a. Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии ). b. Данный тип записи P может быть типом записи предка в любом числе типов связи . c. Данный тип записи P может быть типом записи потомка в любом числе типов связи . d. Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка ; и если L1 и L2 - два типа связи с од ним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила , по которым образуется родство , в разных связях могут различаться . e. Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой . f. Предок и потомок могут быть одного типа записи . Простой пример сетевой схемы БД : 3.3.2. Манипулирова ние данными Примерный набор операций может быть следующим : · Найти конкретную запись в наборе однотипных записей (инженера Сидорова ); · Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310); · Перейти к следующему п отомку в некоторой связи (от Сидорова к Иванову ); · Перейти от потомка к предку по некоторой связи (найти отдел Сидорова ); · Создать новую запись ; · Уничтожить запись ; · Модифицировать запись ; · Включить в связь ; · Исключить из связи ; · Перес тавить в другую связь и т.д . 3.3.3. Ограничения целостности В принципе их поддержание не требуется , но иногда требуют целостности по ссылкам (как в иерархической модели ). 3.4. Достоинства и недостатки Сильные места ранних СУБД : · Развитые средства уп равления данными во внешней памяти на низком уровне ; · Возможность построения вручную эффективных прикладных систем ; · Возможность экономии памяти за счет разделения подобъектов (в сетевых системах ). Недостатки : · Слишком сложно пользоваться ; · Фа ктически необходимы знания о физической организации ; · Прикладные системы зависят от этой организации ; · Их логика перегружена деталями организации доступа к БД. Теоретические основы Мы приступаем к изучению реляционных баз данных и систем управления реляционными базами данных . Этот подход является наиболее распространенным в настоящее время , хотя наряду с общепризнанными достоинствами обладает и рядом недостатков . К числу достоинств реляционного подхода можно отнести : · наличие небольшого набора абс тракций , которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения , оставаясь интуитивно понятными ; · наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных ; · возможность ненавигационного манипулирования данными без необходимости знания конкретной физич еской организации баз данных во внешней памяти . Реляционные системы далеко не сразу получили широкое распространение . В то время , как основные теоретические результаты в этой области были получены еще в 70-х , и тогда же появились первые прототипы реляцион ных СУБД , долгое время считалось невозможным добиться эффективной реализации таких систем . Однако отмеченные выше преимущества и постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому , что уже в сере д ине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД . В настоящее время основным предметом критики реляционных СУБД является не их недостаточная эффективность , а присущая этим системам некоторая ограниченность (прямое след ствие простоты ) при использование в так называемых нетрадиционных областях (наиболее распространенными примерами являются системы автоматизации проектирования ), в которых требуются предельно сложные структуры данных . Еще одним часто отмечаемым недостатком реляционных баз данных является невозможность адекватного отражения семантики предметной области . Другими словами , возможности представления знаний о семантической специфике предметной области в реляционных системах очень ограничены . Современные исследова н ия в области постреляционных систем главным образом посвящены именно устранению этих недостатков . Общие понятия реляционного подхода к организации БД . Основные концепции и термины На этой лекции мы введем на сравнительно неформальном уровне основные поня тия реляционных баз данных , а также определим существо реляционной модели данных . Основной целью лекции является демонстрация простоты и возможности интуитивной интерпретации этих понятий . В дальнейших лекциях будут приводиться более формальные определени я , на которых основывается математическая теория реляционных баз данных 4.1. Базовые понятия реляционных баз данных Основными понятиями реляционных баз данных являются тип данных , домен , атрибут , кортеж , первичный ключ и отношение . Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ , содержащего информацию о сотрудниках некоторой организации : 4.1.1. Тип данных Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования . Обычно в современных реляционных БД допускается хранение символьных , числовых данных , битовых строк , специализированн ых числовых данных (таких как "деньги "), а также специальных "темпоральных " данных (дата , время , временной интервал ). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможнос т ями обладают , например , системы семейства Ingres/Postgres ). В нашем примере мы имеем дело с данными трех типов : строки символов , целые числа и "деньги ". 4.1.2. Домен Понятие домена более специфично для баз данных , хотя и имеет некоторые аналогии с подтип ами в некоторых языках программирования . В самом общем виде домен определяется заданием некоторого базового типа данных , к которому относятся элементы домена , и произвольного логического выражения , применяемого к элементу типа данных . Если вычисление этог о логического выражения дает результат "истина ", то элемент данных является элементом домена . Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа . Например , доме н "Имена " в нашем примере определен на базовом типе строк символов , но в число его значений могут входить только те строки , которые могут изображать имя (в частности , такие строки не могут начинаться с мягкого знака ). Следует отметить также семантическую нагрузку понятия домена : данные считаются сравнимыми только в том случае , когда они относятся к одному домену . В нашем примере значения доменов "Номера пропусков " и "Номера групп " относятся к типу целых чисел , но не являются сравнимыми . Заметим , что в бол ь шинстве реляционных СУБД понятие домена не используется , хотя в Oracle V.7 оно уже поддерживается . 4.1.3. Схема отношения , схема базы данных Схема отношения - это именованное множество пар имя атрибута , имя домена (или типа , если понятие домена не подде рживается ) . Степень или "арность " схемы отношения - мощность этого множества . Степень отношения СОТРУДНИКИ равна четырем , то есть оно является 4-арным . Если все атрибуты одного отношения определены на разных доменах , осмысленно использовать для именовани я атрибутов имена соответствующих доменов (не забывая , конечно , о том , что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута ). Схема БД (в структурном смысле ) - это набор именованных схем отношени й . 4.1.4. Кортеж , отношение Кортеж , соответствующий данной схеме отношения , - это множество пар имя атрибута , значение , которое содержит одно вхождение каждого имени атрибута , принадлежащего схеме отношения . "Значение " является допустимым значением дом ена данного атрибута (или типа данных , если понятие домена не поддерживается ). Тем самым , степень или "арность " кортежа , т.е . число элементов в нем , совпадает с "арностью " соответствующей схемы отношения . Попросту говоря , кортеж - это набор именованных зн а чений заданного типа . Отношение - это множество кортежей , соответствующих одной схеме отношения . Иногда , чтобы не путаться , говорят "отношение-схема " и "отношение-экземпляр ", иногда схему отношения называют заголовком отношения , а отношение как набор корт ежей - телом отношения . На самом деле , понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования . Было бы вполне логично разрешать отдельно определять схему отношения , а затем одно или несколько отношений с данной сх е мой . Однако в реляционных базах данных это не принято . Имя схемы отношения в таких базах данных всегда совпадает с именем соответствующего отношения-экземпляра . В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры . В них могут появляться новые и удаляться или модифицироваться существующие кортежи . Однако во многих реализациях допускается и изменение схемы базы данных : определение новых и изменение существующих схем отношения . Это принято называ т ь эволюцией схемы базы данных . Обычным житейским представлением отношения является таблица , заголовком которой является схема отношения , а строками - кортежи отношения-экземпляра ; в этом случае имена атрибутов именуют столбцы этой таблицы . Поэтому иногда говорят "столбец таблицы ", имея в виду "атрибут отношения ". Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления , мы будем использовать эту житейскую терминологию . Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД . Реляционная база данных - это набор отношений , имена которых совпадают с именами схем отношений в схеме БД . Как видно , основные структурные понятия реляционной модели данных (если не считать понятия домена ) име ют очень простую интуитивную интерпретацию , хотя в теории реляционных БД все они определяются абсолютно формально и точно . Методы , использованные для решения задачи. Базовым инструментом для написания данного проекта был взят Delphi . Открытая архитектура Delphi Компания Borland в развитии своих объектно-ориентированных средств разработки явно пришла к тому выводу , что повторное исполь зование кода и объектная ориентация не являются единственными средствами повышения производительности программистов . С появлением Delphi разработчик может не только создавать и предоставлять своим коллегам готовые к использованию компоненты , но и расширять функциональные возможности среды , в которой он работает , с помощью так называемых "открытых интерфейсов ". Такой подход позволяет использовать Delphi уже в роли общего ядра набора инструментальных средств на всех этапах создания прикладных систем - начиная с CASE-систем и заканчивая генерацией документации по создаваемым проектам , с полной их интеграцией в "святая святых " любой среды программирования - IDE. Рассмотрим основные возможности расширения функциональности среды Delphi для того , чтобы оценить степ ень "открытости " архитектуры этого инструмента. "Строительные блоки " приложений - компоненты Как известно , фундаментальной основой визуальных средств Delphi является компонентный подход . В чем же он заключается ? Delphi строится на базе компилятора объект но-ориентированного языка Object Pascal , продолжающего линию диалектов Pascal - Turbo Pascal и Borland Pascal . По мере своего развития , каждая очередная реализация Pascal компании Borland включала все новые расширения синтаксиса , отражающие последние дости жения в области языков программирования . Если подходить к оценке качественных "ступеней " развития Pascal , особо следует отметить три из них , направленные на поддержку концепции повторного использования кода : · модульная архитектура , с возможностью раздел ения интерфейсной и описательной частей ( Turbo Pascal 4.0 ); · средства объектной ориентации , со всеми , присущими ей характеристиками - наследованием , инкапсуляцией и полиморфизмом ( Turbo Pascal 5.5); · поддержка механизмов RTTI (Run-Time Type Informati on), позволяющих получать информацию о базовых характеристиках объектных типов (классов ) и их экземпляров (объектов ) с помощью языковых средств , непосредственно встроенных в системную библиотеку и структуру организации описаний классов ( Delphi 1.0 - Object Pascal ); Следствием введения поддержки RTTI стала возможность создания визуального инструмента разработки приложений , каковым и является Delphi . На определенном уровне иерархии наследования базовой библиотеки классов Delphi появляется класс TPersistent , обеспечивающий необходимый уровень абстракции потокового ввода /вывода объектов (экземпляров классов ). Его наследником выступает класс TComponent , определяющий основы поведения компонент Delphi VCL (Visual Component Library) в режиме design-time (этап "конс труирования " приложения ). На оконечных точках ветвей иерархии VCL находятся как таковые компоненты - готовые к визуальному использованию классы , непосредственно регистрируемые в рабочей библиотеке компонент и доступные из Палитры Компонент ( Components Pale tte) IDE Delphi . Так как компоненты , используемые в разрабатываемой программе , написаны на том же языке , который используется при создании приложений , программист может достаточно легко создавать и регистрировать в Палитре свои компоненты , наследуя их от т ех или иных представителей иерархии VCL или уже созданных программистом своих классов . С другой стороны , механизмы регистрации и дальнейшего наследования уже существующих стандартов динамического связывания (Windows DLL) и компонентной архитектуры ( VBX в Delphi 1.0 и OCX - в 32- разрядной версии Delphi ) позволяют использовать в Delphi доступные внешние инструменты (например , компиляторы C++) и , созданные с их помощью , программные блоки. Самодостаточность Delphi для расширения набора доступных компонент яв ляется первым признаком открытости архитектуры этого инструмента. Редакторы свойств и редакторы компонент - поведение IDE Логично , что при визуальном подходе к определению характеристик компонент (работа в design- time), необходимы средства определения редакторов специфических свойств в Инспекторе Объектов ( Object Inspector ). Рис . 1 Особенно остро встает для разработчиков компонент вопрос создания и использования редакторов свойств , когда свойства имеют сложный тип . Например , свойство может предоставлять ссылку на достаточно с ложную структуру - запись или на строго определенных наследников одного из стандартных или пользовательских классов (возможные ситуации : 1) класс "множество данных " TDataSet - является предком и таблиц , и запросов , и хранимых процедур ; можно сформулировать такую задачу , когда в качестве значения свойства в design-time должны выступать только запросы и таблицы , но , ни в коем случае - хранимые процедуры ; 2) шрифт описывается рядом характеристик , представляемых вложенными записями ). Delphi предоставляет разработчику ряд базовых классов , входящих в иерархию VCL, которые предназначены для создания редакторов свойств . Рис . 2 Стандартные редакторы свойств (более 20) являются наследниками базовых редакторов и , вместе с последними , доступны программисту для расширения /изменения функциональности , опять-таки , с использованием механизмов наследования и полиморфизма . Регистра ция редакторов свойств и регистрации компонент аналогична регистрации самих компонент . Так как редакторы свойств и редакторы компонент определяют design-time, существование таких редакторов и возможность расширения их функциональности являются вторым приз наком открытости Delphi. Рис . 3 Генерация кода - эксперты В процессе развития и , в том числе , визуализации средств разработки приложений , на фоне стандартизации пользовательского интерфейса в различных областях применения конечных систем , неотъемлемой ча стью таких инструментов стали генераторы кода и форм представления и ввода информации - эксперты . Кроме того , что Delphi включает ряд уже готовых к использованию экспертов (например , DataBase Form Expert , генерирующий формы и соответствующий код для прост ых приложений обработки баз данных с использованием запросов ), эта среда программирования предоставляет разработчикам интерфейс для создания собственных экспертов , встраиваемых в IDE. Необходимо отметить , что функциональность таких экспертов может не огра н ичиваться на генерации кода , в силу того , что интерфейс экспертов дает возможность получения информации о внутренних объектах IDE, таких как палитра компонент . Вследствие этого , под общим названием "эксперты " могут фигурировать программные модули , позволя ю щие управлять повелением IDE, окна дизайнера и ее редактора исходных текстов , а также генерировать отчетную информацию о создаваемом проекте . (На приведенном выше рисунке вы можете увидеть эксперт , разработанный в Delphi и встроенный в IDE; функциональнос т ь этого эксперта заключается в предоставлении разработчику информации об иерархии наследования зарегистрированных компонент без компиляции ; в данном случае доступ осуществляется через меню "Help", хотя возможна регистрация и в "галерее " шаблонов Delphi). Рис . 4 Наличие средств построения программных модулей генерации кода и обработки внутренней IDE- информации , на зываемых экспертами , являются третьим признаком открытости архитектуры Delphi. Интеграция с внешними приложениями - открытые интерфейсы Как следствие возможности обмена информацией с IDE, реальным кажется и интеграция ср еды разработки Delphi с внешними инструментальными средствами - системами контроля версий , мониторами транзакций , CASE - системами и т.п . Рис . 5 И действительно , ряд производителей программных продуктов , относящихся к перечисленным категориям , заявил о поддержке ими Delphi на достаточно высоком уровне интеграции (подразумевая , например , для CASE-систем , не только генерацию кода в соответствии с с интаксисом Object Pascal , но и доступ к таким продуктам непосредственно из IDE). В качестве примера можно привести компанию Popkin Software (производителя CASE-средства System Architect ), объявившую о поддержки Delphi в своих продуктах еще в августе 1995 г ода . Известен ряд систем контроля версий - Intersolv PVCS и MKS Source Integrity , способных работать с Delphi (32-разрядная версия PVCS входит в поставку Delphi Client/Server Suite 2.0 , и , например , мониторов транзакций (существует опыт взаимодействия с No vell Tuxedo и др .). Описанные возможности интеграции с внешними приложениями на базе совокупности открытых интерфейсов , определяют четвертый признак открытости архитектуры Delphi . Delphi – оптимальный инструмент разработчика БД. Наконец , мы можем концептуально представить архитектуру открытых интерфейсов Delphi . Она приведена на следующей диаграмме : Рис . 6 Вследствие такой открытости архитектуры Delphi , большое количество третьих компаний уже выброс ило на рынок (или объявило о соответствующих планах ) как различные расширения библиотеки компонент VCL (более 200 только коммерческих наборов компонент на октябрь 1995г .) так и средства интеграции своих продуктов ( external - site interface ). Получение резул ьтатов. Дипломный проект был условно разбит на четыре этапа. 1) Анализ существующей структуры отделения . Анализ работы отделения. 2) Разработка модели АСУ ОРИТН. 3) Описание АРМа “ОРИТН в порядке”. 4) Внедрение программного продукта. На первом этапе был проведен детальный анализ существующей структуры отделения путем опроса и анкетирования специалистов отделения , ознакомлением с документацией и существующими отчетными формами . Была предложена следующая схема автоматизации отделения . При поступлении больного дежурный врач заносит начальные сведения в базу данных ОРИТН . При занесении больному присваивается уникальный номер и он закрепляется за дежурным врачом на данные сутки . После регистрации активизируется пакет плановых мероприятий , предлагающий де ж урному врачу выбрать и назначить необходимые анализы и процедуры . Данный пакет активизируется на рабочем месте медицинской сестры ежесуточно , которая после проведения конкретной процедуры фиксирует в пакете плановых мероприятий о выполнении или о не выпол н ении . “ОРИТН в порядке” контролирует выполнение всего пакета плановых мероприятий , в случае невыполнения хотя бы одного из пунктов система сигнализирует вплоть до полного завершения всех плановых мероприятий . Дежурный врач в случае необходимости составляе т пакет экстренных мероприятий . Контролирование выполнения данного пакета выполняется аналогично предыдущему . Прекращение работы данных пакетов происходить после заполнения врачом формы о смерти или выписке . Полная история архивируется и остается в базе да н ных “ОРИТН в порядке”. АРМ “ОРИТН в порядке” реализован на языке Delphi . В программе реализованы 8 уровней доступа характеризованные разделением функций персонала по штатному расписанию . 1. Заведующий отделением. 2. Врач ординатор реаниматолог-неонат олог. 3. Старшая медицинская сестра. 4. Процедурная медицинская сестра. 5. Палатная медицинская сестра. 6. Сестра-хозяйка. 7. Санитарка палатная. 8. Санитарка автоклава. У каждого работника персонала есть собственный уникальный пароль на доступ к пр ограмме . В начале каждых суток ”ОРИТН в порядке” закрывает существующие сессии и предлагает новой смене зарегистрироваться . Затем происходит закрепление больных за врачами-ординаторами и медицинскими сестрами . Активизируются пакеты плановых мероприятий на рабочих местах врачей-ординаторов (с возможностью корректировки ) и медицинских сестер . Врач-ординатор анализирует данные за прошедшие сутки и вносит необходимые изменения в один из пакетов . М одуль «Администратор программы «ОРИТН в порядке»» Поскольку разграничение доступа не позволяет корректировать записи в базе данных , появилась необходимость в разработке . Данный модуль позволяет вносить коррективы в любой раздел БД . При загрузке модул ь проверяет наличие прав доступа и в случае наличия полномочий загружает основное окно (рис . 1п ). Рис . 1п В наглядном виде представляются все данные , режим редактирования общепринятый и интуитивно понятный. В виде закладок отображены поля БД , для осуществления операций ввода и удаления предусмотрены кнопочки . Ввод новой записи контролируется на уникальность. Рис . 2п На рис . 2п представлена одна из закладок «персонал». Рис . 3п Суть данного модуля заключается в оперативной корректировке данных по всей базе ОРИТН , поскольку основной модуль исключает возможность удаления данных. Заключение. Модель автоматизации деятельности отделения РИТ Н МГБ № 1 соответствует требованиям разработанным в ходе построения модели . Стандартизированы нами формы отчетности приняты за основу при дальнейшей разработке региональной базы данных по учету больных в данной области медицины . Результатом проектирования с тало написание статистической базы данных “ОРИТН в порядке” версии 1.0 и “модуля администратора” “ОРИТН в порядке” на языке Delphi 3.0. Проделанная работа одобрена руководством отделения РИТН , в лице зав . Отделением Челнокова С.Б. Литература 1. С.Д . Куз нецов “Основы современных баз данных”, http :// www . citforum . ru / database / osbd / contents . shtml 2. К . Дейта , " Введение в системы баз данных ", Наука , 1980. 3. " Руководство по реляционной СУБД DB2 ", Финансы и статистика , 1988. 4. Дж . Ульман " Основы систем баз д анных ", Финансы и статистика , 1983. 5. Материалы 6-й Ежегодной Конференции Разработчиков Borland . 6. Периодические издания (1998 год ): Delphi Informant, Delphi Developer, Microsoft System Journal, Dr. Dobb Journal, Компьютерр - Пресс и др . 7. WWW- серверы : Borland, Miller Friman, Turbo Power, ProtoView, Popkin Software, InterSolv, AOL и др . 8. " Delphi Developers Guide ", S.Tiexeira & X. Pacheco, SAMS Publishing / Borland PRESS. 9. Каталоги программных продуктов " Delphi Only Tools " ZAC Catalog, " Delphi Power Tools " Informant Communications Group. Приложение 1 Задание на дипломное проектирование Студента специальности : 05.13.16 Гудониса Юрия Владимировича Тема : Разработка программного обеспечения для автоматизации работы ОРИТН. Целевая установка : Раз работка базы данных и интерфейса программы для данных на поступающего в отделение больного. Исходные данные : Паспортные данные т.е . Ф.И.О ., дата рождения , дата поступления , рост , вес , диагноз при поступлении и т.д. Начало проектирования : 01.01.98 Конец проектирования : 04.06.98 Содержание работы. 1. Исследование объекта проектирования. 2. Приведение в систему всей вводимой информации. 3. Реализация проекта : · Разработка интерфейса. · Разработка модуля администра тора баз данных “ОРИТН в порядке” 4. Предварительное тестирование программы на месте. 5. Устранение ошибок и дополнение. 6. Окончательная установка программы. Отчетный материал. 1. Пояснительная записка на листах. 2. Гр афики и схемы на листах. Литература . 1. " Delphi Developers Guide " , S.Tiexeira & X. Pacheco, SAMS Publishing / Borland PRESS. 2. Дж . Ульмана " Основы систем баз данных " (Финансы и статистика , 1983). Подписи : Задание получил студент : Ю . В . Гудо нис Руководитель проекта : С . Б . Челноков Зав . Кафедрой : В . А . Острейковский Приложение 2 Исходные тексты программы Модуль «Администратор программы «ОРИТН в порядке»» Main.pas unit Main; interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, ExtCtrls, ComCtrls, StdCtrls, Buttons, ToolWin, Grids, DBGrids, DBCtrls; type TFrmMain = class(TForm) Panel1: TPanel; ToolBar1: TToolBar; BitBtn1: TBitBtn; Pag eControl1: TPageControl; TabSheet1: TTabSheet; TabSheet2: TTabSheet; TabSheet3: TTabSheet; TabSheet4: TTabSheet; TabSheet5: TTabSheet; TabSheet6: TTabSheet; TabSheet7: TTabSheet; TabSheet8: TTabSheet; TabSheet9: TTabShee t; Panel2: TPanel; DBGrid1: TDBGrid; PageControl2: TPageControl; TabSheet10: TTabSheet; TabSheet11: TTabSheet; TabSheet12: TTabSheet; TabSheet13: TTabSheet; DBMemo1: TDBMemo; DBMemo2: TDBMemo; DBMemo3: TDBMemo; DBMemo4: TDBMemo; DBGrid2: TDBGrid; Panel3: TPanel; DBNavigator1: TDBNavigator; Panel4: TPanel; DBNavigator2: TDBNavigator; Panel5: TPanel; Panel6: TPanel; Panel7: TPanel; Panel8: TPanel; Panel9: TPanel; Pane l10: TPanel; Panel11: TPanel; Panel12: TPanel; EditDS: TEdit; BitBtn2: TBitBtn; BtnSAVE: TBitBtn; Panel13: TPanel; DBNavigator3: TDBNavigator; DBGrid3: TDBGrid; BitBtn3: TBitBtn; Panel14: TPanel; Panel15: TPanel; DBNavigator4: TDBNavigator; DBGrid4: TDBGrid; BitBtn4: TBitBtn; BitBtn5: TBitBtn; BtnSAVEENTER: TBitBtn; EditENTER: TEdit; Panel16: TPanel; BitBtn6: TBitBtn; BitBtn7: TBitBtn; BtnSAVEENTER2: TBitBtn; EditENTER2: TEdit; Panel17: TPanel; DBNavigator5: TDBNavigator; DBGrid5: TDBGrid; Panel18: TPanel; BitBtn8: TBitBtn; BitBtn9: TBitBtn; BtnSAVEPERSONAL: TBitBtn; Panel19: TPanel; DBNavigator6: TDBNavigator; EditPE RSONAL: TEdit; DBGrid6: TDBGrid; Panel20: TPanel; BitBtn10: TBitBtn; BitBtn11: TBitBtn; BtnSAVEPTYPE: TBitBtn; EditPTYPE: TEdit; Panel21: TPanel; DBNavigator7: TDBNavigator; DBGrid7: TDBGrid; Panel22: TPanel; Bit Btn12: TBitBtn; BitBtn13: TBitBtn; BtnSAVESTREET: TBitBtn; EditSTREET: TEdit; Panel23: TPanel; DBNavigator8: TDBNavigator; DBGrid8: TDBGrid; Panel24: TPanel; BitBtn14: TBitBtn; BitBtn15: TBitBtn; BtnSAVEVILLAGE: TBitBtn; EditVILLAGE: TEdit; Panel25: TPanel; DBNavigator9: TDBNavigator; DBGrid9: TDBGrid; procedure EditDSChange(Sender: TObject); procedure BitBtn2Click(Sender: TObject); procedure BtnSAVEClick(Sender: TOb ject); procedure EditDSClick(Sender: TObject); procedure BitBtn4Click(Sender: TObject); procedure BitBtn3Click(Sender: TObject); procedure BitBtn5Click(Sender: TObject); procedure BtnSAVEENTERClick(Sender: TObject); procedure EditEN TERChange(Sender: TObject); procedure EditENTERClick(Sender: TObject); procedure BitBtn6Click(Sender: TObject); procedure BitBtn7Click(Sender: TObject); procedure BtnSAVEENTER2Click(Sender: TObject); procedure EditENTER2Change(Sender: T Object); procedure EditENTER2Click(Sender: TObject); procedure BitBtn8Click(Sender: TObject); procedure BitBtn9Click(Sender: TObject); procedure BtnSAVEPERSONALClick(Sender: TObject); procedure EditPERSONALChange(Sender: TObject); procedure EditPERSONALKeyPress(Sender: TObject; var Key: Char); procedure BitBtn10Click(Sender: TObject); procedure BitBtn11Click(Sender: TObject); procedure BtnSAVEPTYPEClick(Sender: TObject); procedure EditPTYPEChange(Sender: TObject) ; procedure EditPTYPEKeyPress(Sender: TObject; var Key: Char); procedure BitBtn12Click(Sender: TObject); procedure BitBtn13Click(Sender: TObject); procedure BtnSAVESTREETClick(Sender: TObject); procedure EditSTREETChange(Sender: TObject ); procedure EditSTREETKeyPress(Sender: TObject; var Key: Char); procedure BitBtn14Click(Sender: TObject); procedure BitBtn15Click(Sender: TObject); procedure BtnSAVEVILLAGEClick(Sender: TObject); procedure EditVILLAGEChange(Sender: TOb ject); procedure EditVILLAGEKeyPress(Sender: TObject; var Key: Char); private Private declarations public Public declarations end; var FrmMain: TFrmMain; implementation uses AdminDM, DB; $R *.DFM procedure TFrmMain.EditDSChange(Sender: TObject); begin With DMAdmin do begin TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]); if (TblDSTITLE.Value <> EditDS.Text) and (EditDS.Text <> '') then BtnSAVE.Enabled := True else BtnSAVE.Enabled := False; TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]); end; end; procedure TFrmMain.BitBtn2Click(Sender: TObject); begin EditDS.Enabled := True; EditDS.SetFocus; end; procedure TFrmMain .BtnSAVEClick(Sender: TObject); begin DMAdmin.TblDS.Insert; DMAdmin.TblDSCODE.Value := DMAdmin.TblDS.RecordCount; DMAdmin.TblDSTITLE.Value := EditDS.Text; DMAdmin.TblDS.Post; DMAdmin.TblDS.Refresh; EditDS.Text := ''; EditDS.Enabled := False; BtnSAVE.Enabled := False; end; procedure TFrmMain.EditDSClick(Sender: TObject); begin With DMAdmin do begin TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]); if (TblDSTITLE.Value <> EditDS.Text) and (EditDS.Text <> '') then BtnSAVE.Enabled := True else BtnSAVE.Enabled := False; TblDS.Locate('TITLE', EditDS.Text, [loPartialKey]); end; end; procedure TFrmMain.BitBtn4Click(Sender: TObject); begin EditENTER.Enabled := True; EditE NTER.SetFocus; end; procedure TFrmMain.BitBtn3Click(Sender: TObject); begin EditDS.Text := ''; EditDS.Enabled := False; BtnSAVE.Enabled := False; end; procedure TFrmMain.BitBtn5Click(Sender: TObject); begin EditENTER.Text := ''; EditENTER.Enabled := False; BtnSAVEENTER.Enabled := False; end; procedure TFrmMain.BtnSAVEENTERClick(Sender: TObject); begin DMAdmin.TblENTERA.Insert; DMAdmin.TblENTERACODE.Value := DMAdmin.TblENTERA.RecordCount; DMAdmin.TblENTERATITLE.Value := EditENTER.Text; DMAdmin.TblENTERA.Post; DMAdmin.TblENTERA.Refresh; EditENTER.Text := ''; EditENTER.Enabled := False; BtnSAVEENTER.Enabled := False; end; procedure TFrmMain.EditENTERChange(Sender: TObject); begin With DMAdmin do begin TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]); if (TblENTERATITLE.Value <> EditENTER.Text) and (EditENTER.Text <> '') then BtnSAVEENTER.Enabled := True else BtnSAVEENTER.Enabled := False; TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]); end; end; procedure TFrmMain.EditENTERClick(Sender: TObject); begin With DMAdmin do begin TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]); if (TblENTERTITLE. Value <> EditENTER.Text) and (EditENTER.Text <> '') then BtnSAVEENTER.Enabled := True else BtnSAVEENTER.Enabled := False; TblENTERA.Locate('TITLE', EditENTER.Text, [loPartialKey]); end; end; procedu re TFrmMain.BitBtn6Click(Sender: TObject); begin EditENTER2.Enabled := True; EditENTER2.SetFocus; end; procedure TFrmMain.BitBtn7Click(Sender: TObject); begin EditENTER2.Text := ''; EditENTER2.Enabled := False; BtnSAVEENTER2.Enabled := False; end; procedure TFrmMain.BtnSAVEENTER2Click(Sender: TObject); begin DMAdmin.TblENTER2A.Insert; DMAdmin.TblENTER2ACODE.Value := DMAdmin.TblENTER2A.RecordCount; DMAdmin.TblENTER2ATITLE.Value := EditENTER2.Text; DMAdmin.TblENTER2A.Post; DMAdmin.TblE NTER2A.Refresh; EditENTER2.Text := ''; EditENTER2.Enabled := False; BtnSAVEENTER2.Enabled := False; end; procedure TFrmMain.EditENTER2Change(Sender: TObject); begin With DMAdmin do begin TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPar tialKey]); if (TblENTER2ATITLE.Value <> EditENTER2.Text) and (EditENTER2.Text <> '') then BtnSAVEENTER2.Enabled := True else BtnSAVEENTER2.Enabled := False; TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPartialKey]); end; end; procedure TFrmMain.EditENTER2Click(Sender: TObject); begin With DMAdmin do begin TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPartialKey]); if (TblENTER2T ITLE.Value <> EditENTER2.Text) and (EditENTER2.Text <> '') then BtnSAVEENTER2.Enabled := True else BtnSAVEENTER2.Enabled := False; TblENTER2A.Locate('TITLE', EditENTER2.Text, [loPartialKey]); end; end; procedure TFrmMain.BitBtn8Click(Sender: TObject); begin EditPERSONAL.Enabled := True; EditPERSONAL.SetFocus; end; procedure TFrmMain.BitBtn9Click(Sender: TObject); begin EditPERSONAL.Text := ''; EditPERSONAL.Enabled := False; BtnSAVEPERSONAL.Enabled := False; end; procedure TFrmMain.BtnSAVEPERSONALClick(Sender: TObject); begin DMAdmin.TblPERSONAL.Insert; DMAdmin.TblPERSONALID.Value := DMAdmin.TblPERSONAL.RecordCount + 1; DMAdmin.TblPERSONALFIO.Value := EditPERSONAL.Tex t; DMAdmin.TblPERSONAL.Post; DMAdmin.TblPERSONAL.Refresh; EditPERSONAL.Text := ''; EditPERSONAL.Enabled := False; BtnSAVEPERSONAL.Enabled := False; end; procedure TFrmMain.EditPERSONALChange(Sender: TObject); begin With DMAdmin do begin TblPERSONAL.Locate('FIO', EditPERSONAL.Text, [loPartialKey]); if (TblPERSONALFIO.Value <> EditPERSONAL.Text) and (EditPERSONAL.Text <> '') then BtnSAVEPERSONAL.Enabled := True else BtnSAVEPERSONAL.En abled := False; TblPERSONAL.Locate('FIO', EditPERSONAL.Text, [loPartialKey]); end; end; procedure TFrmMain.EditPERSONALKeyPress(Sender: TObject; var Key: Char); begin With DMAdmin do begin TblPERSONAL.Locate('FIO', EditPERSONAL.Text, [loPartialKey]); if (TblPERSONALFIO.Value <> EditPERSONAL.Text) and (EditPERSONAL.Text <> '') then BtnSAVEPERSONAL.Enabled := True else BtnSAVEPERSONAL.Enabled := False; TblPERSONAL.Locate('FIO', Ed itPERSONAL.Text, [loPartialKey]); end; end; procedure TFrmMain.BitBtn10Click(Sender: TObject); begin EditPTYPE.Enabled := True; EditPTYPE.SetFocus; end; procedure TFrmMain.BitBtn11Click(Sender: TObject); begin EditPTYPE.Text := ''; EditPTYPE.Enabled := False; BtnSAVEPTYPE.Enabled := False; end; procedure TFrmMain.BtnSAVEPTYPEClick(Sender: TObject); begin DMAdmin.TblPTYPE.Insert; DMAdmin.TblPTYPECODE.Value := DMAdmin.TblPTYPE.RecordCount + 1; DMAdmin.TblPTYPETITLE.Value := EditPTYPE.Text; DMAdmin.TblPTYPE.Post; DMAdmin.TblPTYPE.Refresh; EditPTYPE.Text := ''; EditPTYPE.Enabled := False; BtnSAVEPTYPE.Enabled := False; end; procedure TFrmMain.EditPTYPEChange(Sender: TObject); begin With DMAdmin do begin TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]); if (TblPTYPETITLE.Value <> EditPTYPE.Text) and (EditPTYPE.Text <> '') then BtnSAVEPTYPE.Enabled := True else BtnSAVEPTYPE.Enabled := False; TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]); end; end; procedure TFrmMain.EditPTYPEKeyPress(Sender: TObject; var Key: Char); begin With DMAdmin do begin TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]); if ( TblPTYPETITLE.Value <> EditPTYPE.Text) and (EditPTYPE.Text <> '') then BtnSAVEPTYPE.Enabled := True else BtnSAVEPTYPE.Enabled := False; TblPTYPE.Locate('TITLE', EditPTYPE.Text, [loPartialKey]); end; en d; procedure TFrmMain.BitBtn12Click(Sender: TObject); begin EditSTREET.Enabled := True; EditSTREET.SetFocus; end; procedure TFrmMain.BitBtn13Click(Sender: TObject); begin EditSTREET.Text := ''; EditSTREET.Enabled := False; BtnSAVESTREET.Enabled := False; end; procedure TFrmMain.BtnSAVESTREETClick(Sender: TObject); begin DMAdmin.TblSTREET.Insert; DMAdmin.TblSTREETCODE.Value := DMAdmin.TblSTREET.RecordCount + 1; DMAdmin.TblSTREETTITLE.Value := EditSTREET.Text; DMAdm in.TblSTREET.Post; DMAdmin.TblSTREET.Refresh; EditSTREET.Text := ''; EditSTREET.Enabled := False; BtnSAVESTREET.Enabled := False; end; procedure TFrmMain.EditSTREETChange(Sender: TObject); begin With DMAdmin do begin TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartialKey]); if (TblSTREETTITLE.Value <> EditSTREET.Text) and (EditSTREET.Text <> '') then BtnSAVESTREET.Enabled := True else BtnSAVESTREET.Enabled := F alse; TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartialKey]); end; end; procedure TFrmMain.EditSTREETKeyPress(Sender: TObject; var Key: Char); begin With DMAdmin do begin TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartialKey]) ; if (TblSTREETTITLE.Value <> EditSTREET.Text) and (EditSTREET.Text <> '') then BtnSAVESTREET.Enabled := True else BtnSAVESTREET.Enabled := False; TblSTREET.Locate('TITLE', EditSTREET.Text, [loPartia lKey]); end; end; procedure TFrmMain.BitBtn14Click(Sender: TObject); begin EditVILLAGE.Enabled := True; EditVILLAGE.SetFocus; end; procedure TFrmMain.BitBtn15Click(Sender: TObject); begin EditVILLAGE.Text := ''; EditVILLAGE.Enabled := False; BtnSAVEVILLAGE.Enabled := False; end; procedure TFrmMain.BtnSAVEVILLAGEClick(Sender: TObject); begin DMAdmin.TblVILLAGE.Insert; DMAdmin.TblVILLAGECODE.Value := DMAdmin.TblVILLAGE.RecordCount + 1; DMAdmin.TblVILLAGET ITLE.Value := EditVILLAGE.Text; DMAdmin.TblVILLAGE.Post; DMAdmin.TblVILLAGE.Refresh; EditVILLAGE.Text := ''; EditVILLAGE.Enabled := False; BtnSAVEVILLAGE.Enabled := False; end; procedure TFrmMain.EditVILLAGEChange(Sender: TObject); begin With DMAdmin do begin TblVILLAGE.Locate('TITLE', EditVILLAGE.Text, [loPartialKey]); if (TblVILLAGETITLE.Value <> EditVILLAGE.Text) and (EditVILLAGE.Text <> '') then BtnSAVEVILLAGE.Enabled := True else BtnSAVEVILLAGE.Enabled := False; TblVILLAGE.Locate('TITLE', EditVILLAGE.Text, [loPartialKey]); end; end; procedure TFrmMain.EditVILLAGEKeyPress(Sender: TObject; var Key: Char); begin With DMAdmin do begin TblVILLAGE.Locate('T ITLE', EditVILLAGE.Text, [loPartialKey]); if (TblVILLAGETITLE.Value <> EditVILLAGE.Text) and (EditVILLAGE.Text <> '') then BtnSAVEVILLAGE.Enabled := True else BtnSAVEVILLAGE.Enabled := False; TblVILLAGE.Locate('TITLE', EditVILLAGE.Text, [loPartialKey]); end; end; end. AdminDM.pas unit AdminDM; interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, Db, DBTables; type TDMAdmin = class(TDataMo dule) TblDATA: TTable; DatSrcDATA: TDataSource; TblYEARS: TTable; DatSrcYEARS: TDataSource; TblDATAYEARNUM: TFloatField; TblDATANN: TFloatField; TblDATAHISTORYNUM: TFloatField; TblDATAFIO: TStringField; TblDATABORNDATE: TDateField; TblDATABORNTIMEH: TSmallintField; TblDATABORNTIMEM: TSmallintField; TblDATAENTERDATE: TDateField; TblDATAENTERTIMEH: TSmallintField; TblDATAENTERTIMEM: TSmallintField; TblDATASEX: TSmallintField; TblDATABODYMASS: TFloatField; TblDATABODYLENGHT: TFloatField; TblDATAAPGAR: TStringField; TblDATADN: TSmallintField; TblDATAENTER: TFloatField; TblDATAENTER2: TSmallintField; TblDATAENTERDS: TMemoField; TblDATADS: TFloatFiel d; TblDATADSNOTE: TMemoField; TblDATASTATUS: TFloatField; TblDATASTATUSDATE: TDateField; TblDATASTATUSTIME: TStringField; TblDATASTATUSNOTE: TMemoField; TblDATAADDRESS: TFloatField; TblDATAVILLAGE: TFloatField; TblDATASTREET : TFloatField; TblDATAHOME: TStringField; TblDATAFLAT: TStringField; TblDATAPHONE: TStringField; TblDATANOTE: TMemoField; TblDATAOPERATION: TFloatField; TblDATAYEARs: TIntegerField; TblDATABORNTIMEs: TStringField; TblDATAENT ERTIMEs: TStringField; TblDATASEXs: TStringField; TblDATADNs: TStringField; TblENTER: TTable; DatSrcENTER: TDataSource; TblENTER2: TTable; DatSrcENTER2: TDataSource; TblDATAENTERs: TStringField; TblDATAENTER2s: TStringField; TblDS: TTable; DatSrcDS: TDataSource; TblDATADSs: TStringField; TblDATASTATUSs: TStringField; TblDATAADDRESSs: TStringField; TblSTREET: TTable; DatSrcSTREET: TDataSource; TblVILLAGE: TTable; DatSrcVILLAGE: TDataSource; TblDATASTREETs: TStringField; TblDATAVILLAGEs: TStringField; TblDATA2: TTable; DatSrcDATA2: TDataSource; TblDATA2NN: TFloatField; TblDATA2NEUROL1: TSmallintField; TblDATA2NEUROL2: TSmallintField; TblDATA2NEUROL3: TSmallintFi eld; TblDATA2NEUROL4: TSmallintField; TblDATA2NEUROL5: TSmallintField; TblDATA2NEUROL6: TSmallintField; TblDATA2NEUROL7: TSmallintField; TblDATA2NEUROL8: TSmallintField; TblDATA2NEUROL9: TSmallintField; TblDATA2NEUROL10: TSmallintField; TblDATA2EXT1: TSmallintField; TblDATA2EXT2: TSmallintField; TblDATA2EXT3: TSmallintField; TblDATA2EXT4: TSmallintField; TblDATA2EXT5: TSmallintField; TblDATA2EXT6: TSmallintField; TblDATA2EX T7: TSmallintField; TblDATA2EXT8: TSmallintField; TblDATA2EXT9: TSmallintField; TblDATA2EXT10: TSmallintField; TblDATA2EXT11: TSmallintField; TblDATA2NAMEs: TStringField; TblENTERTITLE: TStringField; TblENTERCODE: TSmallintField ; TblENTER2ENTERID: TSmallintField; TblENTER2TITLE: TStringField; TblENTER2CODE: TSmallintField; TblDSTITLE: TStringField; TblDSCODE: TFloatField; TblSTREETTITLE: TStringField; TblSTREETCODE: TFloatField; TblVILLAGETITLE: TS tringField; TblVILLAGECODE: TFloatField; TblENTER2ENTERs: TStringField; TblENTERA: TTable; DatSrcENTERA: TDataSource; TblENTER2A: TTable; DatSrcENTER2A: TDataSource; TblENTER2AENTERID: TSmallintField; TblENTER2ATITLE: TStringField; TblENTER2ACODE: TSmallintField; TblENTERATITLE: TStringField; TblENTERACODE: TSmallintField; TblENTER2AENTERs: TStringField; TblPERSONAL: TTable; DatSrcPERSONAL: TDataSource; TblPTYPE: TTable; DatSrcPTYPE: TDataSource; TblPERSONALID: TSmallintField; TblPERSONALFIO: TStringField; TblPERSONALNAME1: TStringField; TblPERSONALNAME2: TStringField; TblPERSONALTYPE: TSmallintField; TblPERSONALISACTIVE: TSmallintField; Tbl PERSONALPSW: TStringField; TblPTYPECODE: TSmallintField; TblPTYPETITLE: TStringField; TblPERSONALPTYPEs: TStringField; procedure DMAdminCreate(Sender: TObject); procedure TblDATACalcFields(DataSet: TDataSet); private Private dec larations public Public declarations end; var DMAdmin: TDMAdmin; implementation $R *.DFM procedure TDMAdmin.DMAdminCreate(Sender: TObject); begin TblDATA.Open; TblDATA2.Open; TblYEARS.Open; TblENTER.Open; TblENTER2.Open; TblDS.Open; TblSTREET.Open; TblVILLAGE.Open; TblENTERA.Open; TblENTER2A.Open; TblPERSONAL.Open; TblPTYPE.Open; end; procedure TDMAdmin.TblDATACalcFields(DataSet: TDataSet); begin TblDATABORNTIMEs.Value := IntToStr(TblDATABORNTIMEH.Value) + ':' + IntToStr(TblDATABORNTIMEM.Value); TblDATAENTERTIMEs.Value := IntToStr(TblDATAENTERTIMEH.Value) + ':' + IntToStr(TblDATAENTERTIMEM.Value); Case TblDATASEX.AsInteger of 0: TblDATASexs.Value := ' МУЖ '; 1: TblDATASexs.Value := ' ЖЕН '; else TblDATASexs.Value := '???'; end; Case Case TblDATADN.As Integer of 0: TblDATADNs.Value := ' ДОН '; 1: TblDATADNs.Value := ' НЕД '; else TblDATADNs.Value := '???'; end; Case Case TblDATASTATUS.AsInteger of 0: TblDATASTATUSs.Value := ' БЕЗ ИЗМЕНЕНИЙ '; 1: TblDA TASTATUSs.Value := ' ПЕРЕВЕДЕН '; 2: TblDATASTATUSs.Value := ' УМЕР '; else TblDATASTATUSs.Value := '???'; end; Case Case TblDATAADDRESS.AsInteger of 0: TblDATAADDRESSs.Value := ' СУРГУТ '; 1: TblDATAADDRESSs.Value := ' РАЙОН '; else TblDATAADDRESSs.Value := '???'; end; Case end; end. Доклад Поставленная задача заключалась в разраб отке автоматизированного комплекса учета статистических данных на базе отделения РИТН МГБ № 1. Проведенное устное анкетирование позволило выявить важные моменты организации труда данного отделения , пожелания сотрудников реализовались в разработке статистической базы данных «ОРИТН в порядке». База позволяет осуществить ввод оперативной информац ии для организации лечения . Кроме того , реализован алгоритм наблюдения за исполнением назначенных процедур , не позволяющий отклоняться от указаний дежурного врача . Понятия «пакет плановых мероприятий» и «пакет экстренных мероприятий» переняты из сложившей с я терминологии врачей . «Пакет плановых мероприятий» - совокупность процедур назначаемая дежурным врачом при поступлении больного в отделение , выполняется с периодичностью , активизируется на рабочем месте дежурной сестры , подконтролен модулю наблюдения за исполнением. «Пакет экстренных мероприятий» - совокупность процедур назначаемая дежурным врачом при поступлении больного в отделение на случай ухудшения состояния , выполняется только при регрессии. Результаты мероприятий фиксируются в базе . Статистика выдается в виде отчетных форм , разработанных в ходе проектирования. Накопленные данные , в настоящий момент , оказывают неоспоримую поддержку при оказании консультативных услуг в окружном медико-консультативном центре. РЕФЕРАТ Гудонис Юрий Владимирович. Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии Новорожденных при Муниципальной Городской Больнице № 1 города Сургута . Место дипломирования – Муниципальная Городская Больница № 1, руководитель – Челноков С.Б ., 1998г ., 78 стр ., 2 плаката , 2 приложения. СУБД , базы данных , модель АСУ , одно-ранговые сети , с етевые системы , интернет технологии. Систематизирована существующая информация отделения РИТН МГБ № 1, разработаны формы отчетов , написан , отлажен и внедрен программный мод уль «администратор «ОРИТН в порядке»» для комплекса «ОРИТН в порядке». РЕФЕРАТ Челноков Александр Сергеевич . Разработка программного обеспечения статистических данных для Отделения Реанимации и Интенсивной Терапии Новорожденных при Муниципальной Городск ой Больнице № 1 города Сургута . Место дипломирования – Муниципальная Городская Больница № 1, руководитель – Челноков С.Б ., 1998г ., 115 стр ., 2 плаката , 2 приложения. Открытая архитектура Delphi , системы управления базами данных , экспертные системы , базы да нных , модель АСУ , с ети на базе Novell NetWare , глобальные сети. Проведена работа по систематизации и анализу существующей информации отделения РИТН МГБ № 1. Разработаны формы отчетов . На языке Delphi реализована статистическая база данных «ОРИТН в порядке». Отзыв о дипломной работе. В ходе дипломного проектирования Гудонис Юрий Владимирович проявил себя , как зрелый специалист в области информационных технологий . Выявились глубокие знания своего профиля неподдельный интере с к поставленной задаче . Разработанное программное обеспечение в настоящий момент безотказно работает в тестовом режиме и уже сейчас можно с уверенностью сказать , что данный программный продукт “ОРИТН в порядке” существенно облегчил работу с основными ста т истическими данными . Отделение ОРИТН МГБ № 1 в лице его главного врача С.Б.Челнокова , выражает благодарность Сургутскому Государственному Университету за воспитание высокопрофессиональных , честных и трудолюбивых кадров . В дальнейшем отделение ОРИТН заинтер е сованно в продолжении сотрудничества с авторами данного дипломного проекта . Гудонис Ю.В . удостоен оценки “отлично” и рекомендовано присвоение ему квалификации инженер автоматизированных систем обработки и управления. Главный врач ОРИТН МГБ № 1 г . Сургута, ведущий специалист ОТМУ ХМАО по реанимации и интенсивной терапии новорожденных С.Б.Челноков. Рецензия на дипломную работе «Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии Новорожденных при Муниципальной Гор одской Больнице № 1 города Сургута». На рецензирование был предоставлен программный продукт “ОРИТН в порядке” с модулем “Администратор программы “ОРИТН в порядке” ” реализованный на платформе Delphi , разработанный Челноковым А.С . и Гудонисом Ю.В .. Продук т работоспособен , отвечает поставленным требованиям . Особо следует отметить интуитивно понятный интерфейс , не требующий от пользователя глубоких навыков в работе с компьютером , порадовала красочность отчетов . В целом проект реализован достаточно грамотно и профессионально , но сказывается недостаток опыта в реализации подобных задач , что повлекло за собой допущения ряда незначительных ошибок . Оценка “отлично” , рекомендовано присвоение квалификации инженер автоматизированных систем обработки и управления. Директор АОЗТ “Окружной медицинский Информационно-технический центр” Шепелев А.С.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
У всех разное отношение к Pussy Riot. Только у звёзд отечественного шоу-бизнеса своё особенное.
Они думают: "Блин, кто у них продюсер? Так раскрутить за одно выступление".
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, диплом по программированию "Разработка программного обеспечения для Отделения Реанимации и Интенсивной Терапии новорожденных МГБ N1 г. Сургута", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru