Смекни!
smekni.com

Проектирование базы данных "Риелторская контора" (стр. 2 из 3)

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

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

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться два условия:

- Каждое экземпляр типа P является предком только в одном экземпляре L;

- Каждый экземпляр C является потомком не более чем в одном экземпляре L.

На формирование типов связи не накладываются особые ограничения; возможны, например, ситуации:

а) Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).

б) Данный тип записи P может быть типом записи предка в любом числе типов связи.

в) Данный тип записи P может быть типом записи потомка в любом числе типов связи.

г) Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка; и если L1 и L2 два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.

д) Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.

е) Предок и потомок могут быть одного типа записи.

Примерный набор операций может быть таковым:

· Найти конкретную запись в наборе однотипных записей (инженера Сидорова);

· Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310);

· Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);

· Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);

· Создать новую запись;

· Уничтожить запись;

· Модифицировать запись;

· Включить в связь;

· Исключить из связи;

· Переставить в другую связь и т.д.

К достоинствам сетевой СУБД можно отнести возможность экономии памяти за счет разделения подобъектов.

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software Inc., предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол.

Описанные выше модели данных относятся к так называемым ранним СУБД. У этих моделей есть существенные недостатки так то:

· Слишком сложно пользоваться;

· Фактически необходимы знания о физической организации;

· Прикладные системы зависят от этой организации;

· Их логика перегружена деталями организации доступа к БД.

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

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

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

· наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных;

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

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

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

В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение.

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

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

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

Логическая модель

Рисунок 1 (схема данных)


Информационная модель

Рисунок 2 (Таблица «ИНФО»)

Рисунок 3 (Таблица «Проданные»)

Рисунок 4(Таблица «Риелторы»)

Рисунок 5(Таблица «Договора»)

Рисунок 6(Таблица «Покупатели»)

Интерфейсы

Рисунок 7(Главная кнопочная форма)

Рисунок 8(Карточка покупателя)


Рисунок 9(Карточка риелтора)

Входные данные

Рисунок 10(Таблица «Договора»)

Рисунок 11(Таблица «Инфо»)

Рисунок 12(Таблица «покупатели»)


Рисунок 13(Таблица «риелторы»)

Рисунок 14(Таблица «проданные»)

Выходные данные

Рисунок 15 (результат запроса «каталог»)

Рисунок 16 (результат запроса «имущество за риелтором»)

Рисунок 17 (результат запроса «прибыль»)

Рисунок 18 (результат запроса «продано риелтором»)

Рисунок 19 (результат запроса «проданные»)

Рисунок 20(Отчет «комнат < или >»)


Рисунок 21 (отчет площадь < или >)