Агентство недвижимости. 2

МИНОБРАЗОВАНИЕ РОССИИ

 Федеральное государственное бюджетное образовательное учреждение

 высшего профессионального  образования 

«Ижевский государственный технический университет имени М.Т. Калашникова»

Глазовский инженерно-экономический  институт (филиал)

(ГИЭИ (филиал) ФГБОУ ВПО «ИжГТУ имени М. Т. Калашникова»)

 

Кафедра «Автоматизированные  системы управления»

 

 

 

КУРСОВАЯ РАБОТА

По учебной  дисциплине «Базы данных» на тему: «Агентство недвижимости»

 

 

 

 

 

Выполнил

студент 3 курса, гр. 6451ув___________________________ Н.В. Турунцев

     (подпись)

Проверил

ст. преподаватель___________________________________ Н.Г. Дюкина

 

    (оценка, подпись)

Дата защиты______________

 

 

 

 

 

 

 

 

Глазов, 2013 
СОДЕРЖАНИЕ

 

 

ВВЕДЕНИЕ

 

Любая организация нуждается  в своевременном доступе к  информации. Ценность информации в  современном мире очень высока. Роль распорядителей информации в современном  мире чаще всего выполняют базы данных. Базы данных обеспечивают надежное хранение информации, структурированном виде и своевременный доступ к ней. Практически любая современная организация нуждается в базе данных, удовлетворяющей те или иные потребности по хранению, управлению и администрированию данных.

Целью выполнения курсового  проекта является приобретение студентами практических навыков проектирования баз данных и разработки программного обеспечения по управлению базами данных с использованием СУБД. В ходе выполнения данного курсового проекта необходимо разработать информационную базу данных для больницы, которая поможет любому пользователю легко найти нужную информацию о любом сотруднике или пациенте.

Больница – это такая организация, которая работает с очень большим объемом информации, как о сотрудниках, так и о пациентах. Врачам всегда следить за данными о своих пациентах, о курсе лечения больных. А руководству и бухгалтерии необходимо быть в курсе событий о своих сотрудниках. Для этого нужна общая база данных, включающая всю необходимую информацию. Программа является очень актуальной на сегодняшний день, она автоматизирует работу с базой данных и предоставляет пользователю (оператору) понятный и дружественный интерфейс.

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

 

1. КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ

1.1 Основные понятия

Для начала давайте рассмотрим основные понятия, которые используются при проектировании БД на конкретном уровне.

Концептуальный уровень  проектирования – выявление и описание взаимосвязей между данными на основе изучения предметной области.

Сущности – личности, факты, объекты реального мира, имеющие отношение к некоторой предметной области.

Атрибуты -  данные, описывающие сущности и их взаимосвязей.

Связи – взаимодействия между несколькими сущностями.

Концептуальная  модель – модель данных концептуального уровня.

Концептуальная  схема -  графическое изображение концептуальной модели.

1.2 Описание предметной области

Для проектирования базы данных «Больница» была выбрана следующая  предметная область.

База данных создается для сотрудников больницы, которая будет содержать информацию:

• Данные о врачах: фамилия, имя и отчество, специализация;
• Личные данные пациентов: фамилия, имя и отчество, адрес, телефон, стоимость недвижимости или аренды недвижимости;
• Информация по пациентам: заболевание, дата поступления, дата выписки и т.д.;
• Сведения о процедурах, номерах палаты, принимаемые препараты.

1.3 Выявление сущностей и их  атрибутов

Информация о сущностях  в описании бизнес процессов представлена именами существительными.

Рассмотрим два основных требования, предъявляемые к именам сущности:  

1. имя сущности должно быть стандартным, хорошо определенным и постоянным;
2. имя сущности должно быть существительным в единственном числе (допускается сочетание с прилагательным).

Для описания и характеристики сущностей используются атрибуты.

Разновидности атрибутов:

1. идентифицирующие;
2. связывающие;
3. описывающие.

В предметной области, рассмотренной  ранее, а так же используя копию  отпечатанной базы данных «Больница» выделим следующие сущности с предполагаемыми атрибутами:

1. Сущность

 Личные данные пациента        Атрибуты: Код больного

Фамилия

Имя

Отчество

Дата Рождения 

2. Сущность Врачи    Атрибуты: Код врача

Фамилия

Имя

Отчество

Дата рождения

Специализация

Телефон

3. Сущность Процедура   Атрибуты: Код процедуры

Процедура

4. Сущность Пациент   Атрибуты: Код больного

Код отделения

Код палаты

Код врача

Код заболевания

Код препарата

Дата поступления

Дата выписки

Код операции

Код процедуры

5. Сущность Отделения   Атрибуты: Код отделения

Название

6.  Сущность Палата   Атрибуты: Код палаты

Номер

7.  Сущность Заболевания  Атрибуты: Код заболевания

Заболевание

8.  Сущность Препараты   Атрибуты: Код препарата

Наименование

9.  Сущность Операция   Атрибуты: Код операции

Наименование

1.4 Построение концептуальной схемы

На основе выявленных сущностей можно построить концептуальную схему, определить первичные ключи  и указать связи между сущностями.

Для начала определим, что  такое первичный ключ.

 Первичный ключ – ключ, который гарантирует уникальность каждого экземпляра сущности.

Каждая сущность должна иметь ключ. Ключ может состоять из одного или более атрибутов, значение которых однозначно идентифицирует экземпляр сущности. В то же время  каждая сущность может иметь несколько ключей (они называются потенциальными). Но у каждой сущности есть только один первичный ключ, который выбирается из потенциальных.

Критерии выбора первичного ключа:

1. Ключ должен гарантировать уникальность каждого экземпляра сущности.
2. Атрибуты, входящие в первичный ключ, не могут принимать null – значения.
3. Ключ должен быть неизменным, т.е. не способным и не восприимчивый к изменениям.
4. Значение первичных ключей должны задаваться внутри организации и не должны зависеть от внешних структур.

Концептуальная схема  приведена на рис. 1.1.

 

Концептуальная схема

Рис. 1.1.

Условные обозначения:

1. 

2.  связь 1:М

 3.          связь 1:1

1.5 Определение задач и запросов

Т.к. этой базой данных будут пользоваться сотрудники больницы, определим их основные функции.

Функции:

1. Хранение личных данных пациентов, которые обратились в данное больничное учреждение.
2. Хранение информации о диагнозах, заболеваниях, методах лечения.
3. Хранение информации о врачах и их специальностях.

 

2.ЛОГИЧЕСКИЙ УРОВЕНЬ ПРОЕКТИРОВАНИЯ

Исходные данные для  проектирования:

1. концептуальная модель;
2. качество оценки объема данных и чистоты решения задач;
3. требования к эксплуатационным характеристикам;
4. требования к программному обеспечению;
5. характеристики СУБД;
6. имеющиеся вычислительные ресурсы.

2.1 Краткий обзор логических  структур существующих моделей  данных

В настоящее время  основным средством накопления и  использования структурированной информации служат базы данных. Концептуальный выбор логической модели данных в принципе предопределяет уровень эффективности той или иной программной реализации базы данных.

 

• Различают четыре логические модели данных:
• иерархические;
• сетевые;
• реляционные;
• многомерные.

2.1.1. Иерархическая и сетевая модели БД

Каждая БД содержит и обрабатывает информацию из конкретной прикладной области, представляющей интерес для определенных приложений. Описание предметной области без акцента на ее последующие БД-реализации определяет инфологическую модель предметной области (рис. 2). Инфологическая модель является исходной для построения даталогической модели БД и служит промежуточной моделью для специалистов предметной области (для которой создается БД) и администратора БД в процессе проектирования и разработки конкретной БД.

   

 

Рис. 2.1. Принципиальная организация СОИ на основе БД-технологии

Под даталогической понимается модель, отражающая логические взаимосвязи  между элементами данных безотносительно  их содержания и физической организации. При этом даталогическая модель разрабатывается  с учетом конкретной реализации СУБД, также с учетом специфики конкретной предметной области на основе ее инфологической модели. Для конкретной реализации даталогической модели проектируется физическая модель (рис. 2.1), отображающая первую на конкретные программные и аппаратные средства (ОС, внешняя память, работа с данными на физическом уровне и т.д.). Наполненная конкретной информацией физическая модель и составляет собственно БД. Система, обеспечивающая соответствующее совместное функционирование указанных компонентов и составляет суть конкретной СУБД.

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

 

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

Если в отношении  между данными порожденный элемент  имеет более одного исходного  элемента, то это отношение уже  нельзя описать как древовидную  или иерархическую структуру. Его  описывают в виде сетевой структуры. Любая сетевая структура может быть приведена к более простому виду введением избыточности. «БД постоянно грозит опасность стать громоздкими, застывшими и слишком сложными системами. Новые приложения порождают новые виды запросов пользователей к базе, что увеличивает набор логических связей между ее элементами. В итоге многие системы БД оказываются очень сложными в построении и эксплуатации. Если разработчики не придумают ясные и простые схемы организации, эти системы будут подобны паутине» [К. Дейт].

 

Сетевая модель более  симметрична, чем иерархическая  модель. Однако процедуры (обновления) значительно сложнее проблема состоит  в следующем: всегда имеются две  стратегии для определения места  одного экземпляра записи, первая начинается с "владельца" и просмотра его цепочки для выбора звена, а другая начинается с "подчиненного звена" и просмотра его цепочки для выбора "владельца". Как пользователь может решить, какую стратегию принять? Выбор и здесь имеет большое значение. Как в иерархических, так и сетевых СУБД при описании данных обычно указываются характеристики записей каждого типа, способствующие более эффективному размещению данных во внешней памяти и более быстрому доступу к ним. К таким характеристикам относятся: размеры полей записи (минимальные, средние, максимальные), состав ключа, допустимый набор символов, интервалы значений и т.д.

Иерархические и сетевые  базы данных часто называют базами данных с навигацией. Это название отражает технологию доступа к данным, используемую при написании обрабатывающих программ на языке манипулирования данными. При этом, очевидно, что доступ к данным по путям, не предусмотренным при создании базы данных, может потребовать неразумно большого времени. Повышая эффективность доступа к данным и сокращая таким образом время ответа на запрос, принцип навигации вместе с этим повышает и степень зависимости программ и данных. Обрабатывающие программы оказываются жестко привязанными к текущему состоянию структуры базы данных и должны быть переписаны при ее изменениях. Операции модификации и удаления данных требует переустановки указателей, а манипулирование данными остается записеориентированным. Кроме того, принцип навигации не позволяет существенно повышать уровень языка манипулирования данными, чтобы сделать его доступным пользователю-непрограммисту, или даже программисту-непрофессионалу. Для поиска записи-цели в иерархической или сетевой структуре программист должен вначале определить путь доступа, а затем просмотреть все записи, лежащие на этом пути, - шаг за шагом.

Насколько запутанной являются схемы представления иерархических  и сетевых баз данных, настолько  и трудоемким является проектирование конкретных прикладных систем на их основе. Как показывает, опыт длительные сроки  разработки прикладных систем нередко приводят к тому, что они постоянно находятся в стадии разработки и доработки.

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

2.1.2 Логическая структура реляционной  базы данных

Логическая структура  реляционной базы данных в Access является адекватным отображением полученной информационно-логической модели, не требующим дополнительных преобразований. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура реляционной таблицы определяется реквизитным составом соответствующего информационного объекта, где каждый столбец (поле) соответствует одному из реквизитов объекта. Ключевые реквизиты объекта образуют уникальный ключ реляционной таблицы. Для каждого столбца задается формат и размер данных. Строки (записи) таблицы соответствуют экземплярам объекта и формируются при загрузке таблицы.

 Связи между объектами модели данных реализуются одинаковыми реквизитами – ключами связи в соответствующих таблицах. При этом ключом связи всегда является уникальный ключ главной таблицы. Ключом связи в подчиненной таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа. Ключ связи в подчиненной таблице называется внешним ключом.

 В Access может быть создана схема данных, наглядно отображающая логическую структуру базы данных. Определение одно - многозначных связей в этой схеме должно осуществляться в соответствии с построенной моделью данных. Внешний вид схемы данных практически совпадает с графическим представлением информационно-логической модели. Для модели данных, построенной в рассмотренном примере, логическая структура базы данных в виде схемы данных Access приведена на рис. 2.2.

 На этой схеме  прямоугольники отображают таблицы  БД с полным списком их полей,  а связи показывают, по каким  полям осуществляется взаимосвязь  таблиц. Имена ключевых полей  для наглядности выделены и находятся в верхней части полного списка полей каждой таблицы.

 

 

Рис.2.2. Логическая структура реляционной базы данных предметной области “Больница”

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

2.1.3 Сравнительные характеристики  моделей БД

Таблица 2.1

Вид модели	Достоинства	Недостатки
Иерархическая	- простота понимания; - простота оценки операционных  характеристик;	- отношения М:М могут быть реализованы только искусственно; - могут быть избыточные  данные; - усложняются операции  включения и удаления; - удаление исходных  объектов ведет к удалению  порожденных объектов; - процедурный характер манипулирования данными; - доступ к любому  порожденному узлу возможен только  через корневой узел; - сильная зависимость  логической и

 

Продолжение таблицы 2.1

		физической БД; - сильно ограниченный  набор структур запроса;
Сетевая	- сохранение информации  при уничтожении владельца; - более богатая, чем  в иерархической МД, структура  запросов; - меньшая, чем у  иерархических МД, зависимость логической  и физической БД;	- сложность структуры:  прикладной программист должен детально знать логическую структуру БД (для навигации в наборах и записях); - возможна потеря  независимости данных при реорганизации  БД; - представление в  прикладной программе сложнее,  чем в иерархической МД;
Реляционная	- простота работы и отражение представлений пользователя; - гибкость (соединение, разделение  файлов); - простота внедрения  плоских файлов; - отделение от физической  реализации (независимость); - произвольная структура  запросов; - хорошее теоретическое  обоснование;	- необходимость глубокого  рассмотрения отношений (нормализация), в том числе отношений М:М; - возможность логических  ошибок и необходимость осторожной работы с моделью; - линейность структуры  таблиц.

 

2.2 Требования к эксплуатационным  характеристикам

Эксплуатационные характеристики:

1. Целостность – свойство баз данных, при котором данные удовлетворяют некоторым ограничениям и сохраняют это качество при любых изменениях.
2. Согласованность – свойство базы данных выдавать одинаковые ответы на одновременно заданные одинаковые запросы.
3. Восстанавливаемость – возможность восстановления целостности базы данных после любого сбоя.
4. Безопасность – защита данных от преднамеренного или непреднамеренного доступа, модификации или разрушения.
5. Эффективность – используемые вычислительные ресурсы и время отклика.

2.3 Реляционная модель данных

Реляционная модель данных (РМД) — логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка.

На реляционной модели данных строятся реляционные базы данных.

Реляционная модель данных включает следующие компоненты:

Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

Аспект (составляющая) целостности  — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное  исчисление).

Кроме того, в состав реляционной модели данных включают теорию нормализации.

Термин «реляционный»  означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину  «отношение» часто встречается  слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».

Для лучшего понимания  РМД следует отметить три важных обстоятельства:

• модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;
• для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;
• наличие реляционной алгебры позволяет реализовать декларативное программирование и декларативное описание ограничений целостности, в дополнение к навигационному (процедурному) программированию и процедурной проверке условий.

2.3.1 основные понятия

Атомарные данные – наименьшая единица данных, не разложимая с точки зрения модели.

Домен – множество атомарных значений одного и того же типа.

Атрибут – некоторые подмножество домена, имеющие уникальное имя.

Отношение – некоторое подмножество декартова произведения доменов, имеющее уникальное имя.

Реляционная модель – множество отношений.

Кортеж – множество значений атрибутов отношения по одному значению на атрибут.

2.3.2. Целостность реляционной модели

Целостность данных - это механизм поддержания соответствия базы данных предметной области. В реляционной модели данных определены два базовых требования обеспечения целостности:

• целостность ссылок
• целостность сущностей.

 Целостность сущностей.

 Объект реального  мира представляется в реляционной базе данных как кортеж некоторого отношения. Требование целостности сущностей заключается в следующем: каждый кортеж любого отношения должен отличатся от любого другого кортежа этого отношения (т.е. любое отношение должно обладать первичным ключом).

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

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

Целостность ссылок

 Сложные объекты  реального мира представляются  в реляционной базе данных  в виде кортежей нескольких  нормализованных отношений, связанных  между собой. При этом:

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

 Требование целостности  по ссылкам состоит в следующем:  для каждого значения внешнего  ключа, появляющегося в дочернем  отношении, в родительском отношении  должен найтись кортеж с таким  же значением первичного ключа. 

Пусть, например, даны отношения Пациент (Код больного) и Личные данные пациента (Код больного), в которых хранятся сведения о пациентах, которые лежат в данной больнице. Отношение Пациенты в данной паре является родительским, поэтому его первичный ключ "Код больного" присутствует в дочернем отношении Личные данные пациента.