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

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

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

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

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

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

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

 

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

 

 

 

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

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

 

 

 

 

 

Выполнил

студент 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), отображающая первую на конкретные программные и аппаратные средства (ОС, внешняя память, работа с данными на физическом уровне и т.д.). Наполненная конкретной информацией физическая модель и составляет собственно БД. Система, обеспечивающая соответствующее совместное функционирование указанных компонентов и составляет суть конкретной СУБД.

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

 

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

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