афыыф. Курсовой проект III. Инструкция по использованию бд 34 Вызов программы 34 Экранные формы 35 Описание отчетов 37 Заключение 39
 Скачать 3.84 Mb.
|
|
СОДЕРЖАНИЕвыфы Введение 3 Аннотация 4 Обследование предметной области 5 Концептуальное проектирование 8 Инфологическое проектирование БД 10 Модель «сущность-связь» 10 Классификация связей 12 Реляционная модель БД 14 Функциональные зависимости между атрибутами 15 Выбор ключей 17 Определение отношений между таблицами 20 Нормализация отношений 20 Даталогическое проектирование БД 22 Состав таблиц БД 22 Средства поддержания целостности 24 Запросы к БД 29 Разработка механизмов защиты данных от несанкционированного доступа 30 Требования к техническому обеспечению 33 Инструкция по использованию БД 34 Вызов программы 34 Экранные формы 35 Описание отчетов 37 Заключение 39 Список литературы 40 Приложения 41 ВВЕДЕНИЕ В настоящие время в связи с развитием компьютерной техники появилась возможность автоматизировать многие процессы, также увеличился объем обрабатываемой информации. И возникла объективная необходимость автоматизировать систему учета и регистрации для медицинских страховых компаний. Для автоматизации обработки данных в начале 70-х годов были предложены программы, специально предназначенные для управления данными – системы управления базами данных (СУБД). Что такое базы данных?В самом общем смысле база данных - это набор записей и файлов, организованных специальным образом. В компьютере, например, можно хранить фамилии и адреса друзей или клиентов. Один из типов баз данных - это документы, набранные с помощью текстовых редакторов и сгруппированные по темам. Другой тип - файлы электронных таблиц, объединяемые в группы по характеру их использования. Первые модели данных.С ростом популярности СУБД в 70-80-х годах появилось множество различных моделей данных. У каждой из них имелись свои достоинства и недостатки, которые сыграли ключевую роль в развитии реляционной модели данных, появившейся во многом благодаря стремлению упростить и упорядочить первые модели данных. В зависимости от способа установления связей между данными с компьютерно–ориентированным описанием на языке конкретной СУБД, разрабатывались различные модели логической организации данных: иерархическая, сетевая и реляционная. Использование баз данных и информационных систем становится неотъемлемой составляющей деловой деятельности современного человека и функционирования преуспевающих организаций. В связи с этим большую актуальность приобретает освоение принципов построения и эффективного применения соответствующих технологий и программных продуктов: систем управления базами данных, CASE-систем автоматизации проектирования, средств администрирования и защиты баз данных и других. От правильного набора инструментальных средств создания информационных систем, определения подходящей модели данных, обоснования рациональной схемы построения баз данных, организация запросов к хранимым данным и ряда других моментов во многом зависят эффективность функционирования разрабатываемых систем. Все это требует осознанного применения теоретических положений и инструментальных средств разработки баз данных и информационных систем. Целью данного курсового проекта является создание автоматизированной системы ''Медицинская страховая компания'' для данной компании. Для этого необходимо создать базу данных, содержащую сведения о пациентах, регистрирующихся в медицинской страховой компании. СУБД Microsoft Visual Fox Pro 6.0 представляет собой инструмент, позволяющий реализовать поставленную цель. Достижение цели осуществляется посредством комплекса задач: проектирование и создание таблиц для хранения данных; ввод данных; разработка других элементов базы, предназначенных для просмотра, редактирования и вывода информации. Также курсовой проект содержит требования к техническому обеспечению и инструкцию по использованию БД. АННОТАЦИЯВ ходе выполнения курсового проекта была создана база данных "Медицинская страховая компания" в современной системе управления базами данных – Microsoft Visual FoxPro 6.0. В базу входит ряд таблиц с данными, полученными при обследовании предметной области. Созданная база должна существенно облегчить, а также автоматизировать работу системы в данной компании. Проектирование базы данных осуществлялось методом нормальных форм, который является классическим методом проектирования реляционных баз данных. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ Основанием для проектирования базы данных «Медицинская страховая компания» послужило задание Северо-Кавказского Государственного Технического университета (филиал в городе Кисловодске). Управление процессом страхования включает в себя множество серьёзных задач. Разработка базы данных «Медицинская страховая компания» должна обеспечить решение следующих проблем: Visual Fox Pro – представляет собой СУБД реляционного типа с развитыми средствами созданиями БД, организации запросов к ним, построения приложений с использованием визуального, объектно-ориентированного программирования. СУБД Visual Fox Pro может работать в среде Windows XP и Windows 2000. Visual Fox Pro 6 совместима с более ранними версиями Fox Pro. Поэтому приложения, разработанные в более ранних версиях, могут быть адаптированы с ее помощью в среду Windows XP. Visual Fox Pro обладает высокой скоростью в обслуживании баз данных. Используемый стандарт SQL- запроса для выборки данных Visual Fox Pro позволяет работать с базами данных таких СУБД как Access, dBase и т.д., с серверами БД – Microsoft SQL Server. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ Сущность (essence) – сущность объект любой природы, данные о котором хранятся в базе данных. Данные о сущности хранятся в отношении. Отношение является важнейшим понятием в реляционной модели данных и представляет собой двумерную таблицу, содержащую некоторые данные. Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствуют заголовки некоторого столбца таблицы. Сущность 1 – pacient; Атрибуты: Код; Фио; Год_рожд; Адрес; Ном_полиса; Код_страх_ком. Сущность 2 – poliklinika; Атрибуты: Код; Название. Сущность 3 – registracia; Атрибуты: Код_пац; Кол_пол_ки; Код_заб; Фио_врача; Спец_врача; Дата_начала; Дата_окон; Дата_перв; Кол_пос; Кол_дом; Проф_осм; Плата. Сущность 4 – strah_kompania; Атрибуты: Код; Название; Доп_инф. Сущность 5 – zabolevanie. Атрибуты: Код; Название. Обоснованием выбора данных сущностей являются исходные данные к проекту, которые были разбиты на отдельные части (таблицы) по принципу соответствия. Выходная информация на экран: -списки пациентов с указанным кодом заболевания по всем поликлиникам; -суммарное количество посещений на дому для заданной поликлиники. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Модель «Сущность-связь» Наиболее часто формализация представлений о предметной области осуществляется в рамках модели «сущности-связи» («объекты-связи»). На данном этапе проектирования используется метод «сущность – связь», который называют также методом «ER-диаграмм» (“Essence” – сущность, “Relation” – связь). Этот метод основан на использовании диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа. Основными понятиями метода сущность – связь являются следующие: сущность; атрибут сущности; ключ сущности; связь между сущностями; степень связи; класс принадлежности экземпляров сущности; диаграммы ER-экземпляров; диаграммы ER-типа. Под информационным объектом понимается некоторая сущность фрагмента действительности, например: организация, документ, сотрудник, место, событие и т. д. Сущность представляет собой объект, информация о котором хранится в базе данных. Экземпляры сущности отличаются от друг друга и однозначно идентифицируются. Названием сущности являются имена существительные. Каждый тип объектов идентифицируется присущим ему набором атрибутов. Атрибут ((от лат. attribuo – приписываю) – свойство или вещь, неотделимые от предмета) представляет собой логически неделимый элемент структуры информации, характеризующийся множеством атомарных значений. Это понятие аналогично понятию «атрибут» в отношении. Экземпляр объекта характеризуется совокупностью конкретных значений атрибутов данного типа объекта. Один или некоторая группа атрибутов объекта данного типа могут исполнять роль ключевого атрибута (ключа сущности). Ключ сущности – это атрибут или набор атрибутов, идентифицирующих экземпляр сущности. Связь двух или более сущностей – это зависимость между атрибутами этих сущностей. Оно обозначается глаголом. Причём связи бывают двух типов: иерархические; одноуровневые. Для повышения наглядности и удобства проектирования используются графические средства представления сущности, экземпляров сущности и связей между ними.  рис 1. ER-диаграмма Классификация связей В реальных базах данных информация размещается в нескольких таблицах. Таблицы при этом связаны семантикой информации. В реляционных СУБД для указания связей таблиц производят операцию их связывания. Это повышает достоверность хранимой в базе информации, т. к. СУБД контролирует целостность данных, вводимых в базу в соответствии с установленными связями. Установление связей облегчает доступ к данным при выполнении операций: поиск, просмотр, редактирование, выработка и подготовка отчета, т.к. обеспечивается обращение к любым полям связанных таблиц. Между таблицами могут устанавливаться: - бинарные связи; - тернарные связи; - n-арные связи. При связывании двух таблиц выделяют основную и подчиненную таблицы (родительскую и дочернюю). Логическое связывание таблиц производится с помощью ключа связей. Поля основной таблицы могут быть простыми и ключевыми. Поля связей дополнительной таблицы чаще всего ключевые. В зависимости от того, как определены поля связи основной и дополнительной таблиц (как относятся ключевые поля с полями связи), устанавливаются виды связей: 1:1 (один к одному); 1:М (один ко многим); М:1 (многие к одному); М:М (многие ко многим). Связь вида 1:1 образуется, если все поля связи родительской и дочерней таблиц являются ключевыми. Поскольку значения в ключевых полях двух таблиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными. Связь вида 1:М имеет место в случае, когда одной записи родительской таблицы соответствует несколько записей дочерней таблицы. Связь М:1 имеет место в случае, когда одной ил нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы. Связь М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы. Аналогично связи 1:1, связь М:М не устанавливает подчиненность таблиц. На практике в связь обычно вовлечены несколько таблиц. При этом одна таблица может иметь различные виды связи с несколькими таблицами, образуя иерархию или «дерево связей». 4. РЕЛЯЦИОННАЯ МОДЕЛЬ БАЗЫ ДАННЫХ В реляционных базах данных (RelationalDatabaseSystem, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL(IBM), Quel(Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД. Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. Язык SQL был создан в начале 70‑х как интерфейс для взаимодействия с базами данных, основанными на новой для того времени реляционной теории. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2 (или SQL-92), включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений. Строки таблицы составлены из полей, заранее известных базе данных. В большинстве систем нельзя добавлять новые типы данных. Каждая строка в таблице соответствует одной записи. Положение данной строки может изменяться вместе с удалением или вставкой новых строк. Чтобы однозначно определить элемент, ему должны быть сопоставлены поле или набор полей, гарантирующих уникальность элемента внутри таблицы. Такое поле или поля называются первичным ключом (primarykey) таблицы и часто являются числами. Если одна таблица содержитпервичным ключ другой, это позволяет организовать связь между элементами разных таблиц. Это поле называется внешним ключом (foreignkey). Так как все поля одной таблицы должны содержать постоянное число полей заранее определенных типов, приходится создавать дополнительные таблицы, учитывающие индивидуальные особенности элементов, при помощи внешних ключей. Такой подход сильно усложняет создание сколько-нибудь сложных взаимосвязей в базе данных. Еще один крупный недостаток реляционных баз данных – это высокая трудоемкость манипулирования информацией и изменения связей. 4.1 Функциональные зависимости между атрибутами Таблица 1 – Функциональные зависимости между атрибутами сущности «pacient».
Таблица 2 – Функциональные зависимости между атрибутами сущности «poliklinika».
Таблица 3– Функциональные зависимости между атрибутами сущности«registracia»
Таблица 4 – Функциональные зависимости между атрибутами сущности «strah_kompania»
Таблица 5 – Функциональные зависимости между атрибутами сущности «zabolevanie»
4.2 Выбор ключей Первичный ключ используется в Visual Fox Pro при определении отношений между таблицами и условий целостности данных. Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут отношения, однозначно идентифицирующих каждый из его кортежей. Например, в отношении zabolevanie (Код, Название) ключевым является атрибут «Код». Ключ может быть составным (сложным), т.е. состоять из нескольких атрибутов. Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Её существование гарантируется тем, что отношение это множество, которое не содержит одинаковых элементов – кортежей. Т.е. в отношении нет повторяющихся кортежей, а это значит, что по крайней мере вся совокупность атрибутов обладает свойством однозначной идентификации кортежей отношения. Во многих СУБД допускается создавать отношения, не определяя ключи. Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный. Ключи обычно используют для достижения следующих целей: исключение дублирование значений в ключевых атрибутах (остальные атрибуты в расчет не принимаются); упорядочения кортежей. Возможно упорядочение по возрастанию или убыванию значений всех ключевых атрибутов, а также смешанное упорядочение (оп одним - возрастание, а по другим – убывание); ускорение работы к кортежам отношения; организация связанных таблиц. Реляционная модель накладывает на внешние ключи ограничение для обеспечения целостности данных, называемое ссылочной целостностью. Это означает, что каждому значению внешнего ключа должны соответствовать строки в связываемых отношениях. Поскольку не всякой таблицы можно поставить в соответствие отношение, приведём условия, выполнение которых позволяет таблицу считать отношением. Все строки таблицы должны быть уникальны, т.е. не может быть строк с одинаковыми первичными ключами. Имена столбцов таблицы должны быть различны, а значения их простыми, т.е. недопустима группа значений в одном столбце одной строки. Все строки одной таблицы должны иметь одну структуру, соответствующую именам и типам столбцов. Порядок размещения строк в таблице может быть произвольным. Наиболее часто таблиц с отношением размещается в отдельном файле. В некоторых СУБД одна отдельная таблица (отношение) считается базой данных. В других СУБД база данных может содержать несколько таблиц. Таблица данных обычно хранится на магнитном диске отдельном файле операционной системы, поэтому по её именованию могут существовать ограничения. Имена полей хранятся внутри таблиц. Правила их формирования определяются СУБД, которые, как правило, на длину полей и используемый алфавит серьёзных ограничений не накладывают. Если задаваемое таблицей отношение имеет ключ, то считается, что таблица тоже имеет ключ и её называют ключевой или таблицей с ключевыми полями. У большинства СУБД файл таблицы включает управляющую часть (описание типов полей, имена полей другая информация) и область размещения записей. Файл таблицы включает управляющую часть (описание типов полей, имена полей и другая информация) и область размещения записей. К отношениям можно применять систему операций позволяющих получать одни отношения из других. Первичному ключу родительской сущности, обычно соответствует несколько записей дочерней или подчиненной. Разработанная база данных «Медицинская страховая компания» состоит из 5 таблиц, 4 из них обладают первичными ключами: 1. pacient; 2. strah_kompania;   3. poliklinika; 4. zabolevanie;   5. registracia.  4.3. Определение отношений между таблицами В Visual FoxPro можно устанавливать постоянные отношения между таблицами. При определении отношений одна таблица является родительской, а другая дочерней. Для родительской таблицы должен быть определен первичный ключ или ключ-кандидат, а для дочерней - индекс для связи с родительской таблицей. 4.4. Нормализация отношений. |
