Курсовая база данных Агенство недвижимости

 

3) Сущность КЛИЕНТЫ.

• Код клиента (Код Клиента);
• ФИО клиента (ФИО Клиента);
• Адрес (Адрес);
• Контактный теелфон (Телефон);
• Код объекта (КодОбъекта).

 

4) Сущность ОБЪЕКТЫ.

• Код объекта (КодОбъекта);
• Тип объекта (ТипОбъекта);
• Тип операции (ТипОперации);
• Адрес объекта (АдресОбъекта);
• Количество комнат (КоличествоКомнат);
• Общая площадь (ОбщаяПлощадь);
• Жилая площадь (ЖилаяПлощадь);
• Этаж (Этаж);
• Этажность (Этажность);
• Стоимость (Стоимость).

 

5) Сущность ТИПЫ ОБЪЕКТОВ.

• Код типа объекта (КодТипаОбъекта);
• Наименование типа объекта (НаименованиеТипаОбъекта).

 

6) Сущность ОПЕРАЦИИ.

• Код операции (КодОперации);
• Код типа операции (КодТипаОперации);
• Дата операции (ДатаОперации);
• Код организации (КодОрганизации);
• Код клиента (КодКлиента);
• Код объекта (КодОбъекта);
• Код сотрудника (КодСотрудника);
• Стоимость (Стоимость).

 

7) Сущность ТИПЫ ОПЕРАЦИЙ:

• Код типа операции (КодТипаОперации);
• Наименование типа операции (НаименованиеТипаОперации).

 

2.2 Нормализация  информационных объектов

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

Результатами анализа  проведенного в предыдущем разделе стали 7 сущностей: ОРГАНИЗАЦИЯ, СОТРУДНИКИ, КЛИЕНТЫ, ОБЪЕКТЫ, ТИПЫ ОБЪЕКТОВ, ОПЕРАЦИИ, ТИПЫ ОПЕРАЦИЙ . Каждая сущность характеризуется группой атрибутов, часть из которых может дублироваться в других сущностях. Для оптимизации данных необходимо провести процедуру нормализации, которая выполняется поэтапно.

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

Для приведения сущностей к таблицам первой нормальной форме, необходимо исключить дублирование множества характеристик между двумя сущностями, путем присвоения ключевых атрибутов тем сущностям, которые их не имеют. Так, например, для определения объекта недвижимости, принадлежащего клиенту в сущности КЛИЕНТЫ нет необходимости дублировать характеристики сущности ОБЪЕКТЫ, достаточно внести в атрибуты сущности КЛИЕНТЫ ключевое поле: Код Объекта (КодОбъекта). А в сущности ОБЪЕКТЫ заменить атрибут «Номер объекта» на «Код Объекта», и в дальнейшем связать две этих сущности через созданное поле. Аналогичным образом по необходимости добавляются ключевые атрибуты к другим сущностям.

Для второй нормальной формы (2НФ) требуется, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. Значение первичного ключа в таблице БД должно быть уникальным, т.е. в таблице не должно существовать двух и более записей с одинаковым значением первичного ключа. Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц. Примером приведение таблиц ко второй нормальной форме, является разделение сведений о счетах на две сущности ТИПЫ ОПЕРАЦИЙ и ТИПЫ ОБЪЕКТОВ.

Для третьей  нормальной формы (ЗНФ) требуется, чтобы  все не ключевые столбцы таблицы зависели от первичного ключа таблицы, но были независимы друг от друга. Для этого требуется, чтобы таблицы были приведены к 1НФ и 2НФ.

В результате проведения нормализации были выявлены сущности ТИПЫ ОПЕРАЦИЙ и ТИПЫ ОБЪЕКТОВ.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.3 Построение ИЛМ в виде диаграммы «Таблица-связь»

Рисунок 2. Инфологическая модель в виде диаграммы «Таблица-связь»

 

3. РАЗРАБОТКА ДАТАЛОГИЧЕСКОЙ МОДЕЛИ

3.1 Описание выбранной СУБД

Реляционная база данных представляет собой множество взаимосвязанных таблиц, каждая из которых содержит информацию об объектах определенного типа.

Наиболее удобной и  популярной системой управления базой  данных (СУБД), которая позволит реализовать  все необходимые задачи по разработке базы данных и программного приложения является продукт компании Microsoft – Access.

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

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

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

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

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

Access может поддерживать одновременную работу с базой данных 50 пользователей, при этом все пользователи гарантировано будут работать с актуальными данными.

3.2  Представление концептуальной схемы в виде таблиц реляционной базы данных с данными контрольного примера и описанием логической структуры таблиц

Ниже представлены сущности и их атрибуты в виде таблиц реляционной базы данных (РБД) с описанием ограничений и примером заполнения.

Таблица 1. Таблица  «Организация»

Поле		Данные контрольного примера
(*)КодОрганизации
Наименование	Риэлтерское агентство  «Контакт - недвижимость»
ИНН	5739075286
КПП	360753965
Адрес	119002, Москва, Гагаринский пер., д. 33
Телефон	(495) 221-8031
Руководитель	Артёмов Игорь Геннадиевич
Главный бухгалтер	Крашинникова Мария  Егоровна
Расчетный счет	87653450984673478905
БИК	044525593
Банк	ОАО «АЛЬФА-БАНК»
К/С	87653450984673478905

Таблица 2. Описание логической структуры таблицы «Организация»

Поле	Тип данных	Ограничения
(*)КодОрганизации	Счетчик	Последовательное Уникальное
Наименование	Текстовый (255)	Не более 255 символов
ИНН	Текстовый (10)	10 цифр
КПП	Текстовый (9)	9 цифр
Адрес	Текстовый (255)	Не более 255 символов
Телефон	Текстовый (20)	Не более 20 символов
Руководитель	Текстовый (50)	Не более 50 символов
Главный бухгалтер	Текстовый (50)	Не более 50 символов
ОКПО	Текстовый (8)	8 цифр
Расчетный счет	Текстовый (20)	20 цифр
БИК	Текстовый (9)	9 цифр
Банк	Текстовый (50)	Не более 100 символов
К/С	Текстовый (20)	20 цифр

 

Таблица 3. Таблица  «Клиенты»

Поле	Контрольный пример 1	Контрольный пример 2
(*)КодКлиента	1	2
ФИОКлиента	Иванов Петр Михайлович	Федоров Иван Михайлович
Адрес Проживания	ул. Абельмановская, дом 2, кв. 11	ул. Козловская, дом 55, кв 59
Контактный телефон	(495) 167-56-43	(495) 453-73-45

Таблица 4. Описание логической структуры таблицы «Клиенты»

Поле	Тип данных	Ограничения
(*)КодКлиента	Счетчик	Последовательное, Уникальное
ФИОКлиента	Текстовый (50)	Не более 50 символов
Адрес Проживания	Текстовый (50)	Не более 50 символов
Контактный телефон	Текстовый (20)	Не более 20 символов

 

Таблица 5. Таблица  «Сотрудники»

Поле	Контрольный пример 1	Контрольный пример 2
(*)КодСотрудника	1	2
ФИО Сотрудника	Петелина Виктория Александровна	Романенко Марина Александровна
Дата рождения	07.09.1986	10.04.1981
Паспортные данные	18 05 802978	18 05 809858
Адрес проживания	ул. Новокузнецкая, дом 2, кв. 11	ул .Новокрюковская, дом 11, кв. 34
Контактный телефон	(495) 753-45-34	(495) 742-58-54

Таблица 6. Описание логической структуры таблицы «Сотрудники»

Поле	Тип данных	Ограничения
(*)КодСотрудника	Счетчик	Последовательное, Уникальное
ФИО Сотрудника	Текстовый (50)	Не более 50 символов
Дата рождения	Дата/время	Краткий формат
Паспортные данные	Текстовый (20)	Не более 20 символов
Адрес проживания	Текстовый (50)	Не более 50 символов
Контактный телефон	Текстовый (20)	Не более 20 символов

Таблица 7. Таблица  «Объекты»

Поле	Контрольный пример 1	Контрольный пример 2
(*)КодОбъекта	1	2
(*)КодТипаОперации	1	1
(*)КодТипаОбъекта	1	2
АдресОбъекта	ул. Гиляровского, дом 5, кв. 56	ул. Герасима Курина, дом 2, кв. 45
КоличествоКомнат	4	3
ОбщаяПлощадь	59,5	79,5
ЖилаяПлощадь	33,4	53,5
Этаж	6	20
Этажность	8	21
Стоимость	12500000руб.	13200000руб.

Таблица 8. Описание логической структуры таблицы «Клиенты»

Поле	Тип данных	Ограничения
(*)КодОбъекта	Счетчик	Последовательное, Уникальное
(*)КодТипаОперации	Числовой	Длинное целое
(*)КодТипаОбъекта	Числовой	Длинное целое
АдресОбъекта	Текстовый (50)	Не более 50 символов
КоличествоКомнат	Числовой	Длинное целое
ОбщаяПлощадь	Числовой	Длинное целое, 1 знак после  запятой
ЖилаяПлощадь	Числовой	Длинное целое, 1 знак после  запятой
Этаж	Числовой	Длинное целое
Этажность	Числовой	Длинное целое
Стоимость	Денежный	2 знака после запятой

 

Таблица 9. Таблица «Операции»

Поле	Контрольный пример 1	Контрольный пример 2
(*) КодОперации	1	2
ДатаОперации	19.06.2009	22.06.2009
(*) КодТипаОперации	1	2
(*) КодОрганизации	1	1
(*) КодКлиента	3	4
(*) КодОбъекта	2	5
(*) КодСотрудника	3	3
Стоимость	12400000руб.	27000руб.