p align="left">Фактически необходимы знания о физической организации; Прикладные системы зависят от этой организации; Их логика перегружена деталями организации доступа к БД. В условия современного развития компьютерной техники, когда с базами данных всё чаще работают непрофессионалы, делает эти СУБД весьма сложными для обслуживания. Реляционная модель данных. Данная модель является наиболее распространенной в настоящее время, хотя наряду с общепризнанными достоинствами обладает и рядом недостатков. К числу достоинств реляционного подхода можно отнести: наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать большую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными; наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных; возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти. В настоящее время основным предметом критики реляционных СУБД является не их недостаточная эффективность, а присущая этим системам некоторая ограниченность (прямое следствие простоты) при использование в так называемых нетрадиционных областях (наиболее распространенными примерами являются системы автоматизации проектирования), в которых требуются предельно сложные структуры данных. Наиболее распространенная трактовка реляционной модели данных, по-видимому, принадлежит Дейту. Согласно Дейту реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части. В структурной части модели фиксируется, что единственной структурой данных, используемой в реляционных БД, является нормализованное n-арное отношение. В манипуляционной части модели утверждаются два фундаментальных механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление. Первый механизм базируется в основном на классической теории множеств (с некоторыми уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого порядка. Относительная простота и эффективность РСУБД, а также наличие солидной теоретической базы сделало эту модель данных наиболее распространённой на сегодняшний день. Абсолютное большинство систем управления базами данных, присутствующих на рынке программного обеспечения основываются именно на реляционной модели. Исходя из вышесказанного, мне представляется логичным использовать для выполнения отчета реляционную модель данных. Логическая модельРисунок 1 (схема данных) Информационная модельРисунок 2 (Таблица «ИНФО»)
Рисунок 3 (Таблица «Проданные»)
Рисунок 4(Таблица «Риелторы»)
Рисунок 5(Таблица «Договора»)
Рисунок 6(Таблица «Покупатели») ИнтерфейсыРисунок 7(Главная кнопочная форма)
Рисунок 8(Карточка покупателя)
Рисунок 9(Карточка риелтора) Входные данныеРисунок 10(Таблица «Договора»)
Рисунок 11(Таблица «Инфо») Рисунок 12(Таблица «покупатели») Рисунок 13(Таблица «риелторы») Рисунок 14(Таблица «проданные») Выходные данныеРисунок 15 (результат запроса «каталог») Рисунок 16 (результат запроса «имущество за риелтором») Рисунок 17 (результат запроса «прибыль») Рисунок 18 (результат запроса «продано риелтором»)
Рисунок 19 (результат запроса «проданные»)
Рисунок 20(Отчет «комнат < или >») Рисунок 21 (отчет площадь < или >)
Рисунок 22 (отчет сумма < или >)
Рисунок 23(Отчет «тип») Алгоритм решения задачиЗапросы SQLSQL является, прежде всего, информационно-логическим языком, предназначенным для описания хранимых данных, для извлечения хранимых данных и для модификации данных. SQL не является языком программирования. (Вместе с тем стандарт языка спецификацией SQL/PSM предусматривает возможность его процедурных расширений.)Изначально, SQL был основным способом работы пользователя с базой данных и представлял собой небольшую совокупность команд (операторов) допускающих создание таблиц, добавление в таблицы новых записей, извлечение записей из таблиц (в соответствии с заданным условием), удаление записей и изменение структур таблиц. В связи с усложнением язык SQL стал более прикладным языком программирования, а пользователи получили возможность использовать визуальные построители запросов.Запрос «Каталог» - данный запрос выбирает из таблицы «ИНФО» информация о имуществе.SELECT ИНФО.№_договора, ИНФО. тип, ИНФО. Площадь_ кв_ метр, ИНФО. Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО. , Риелторы.ФИО Риелтора, Риелторы.телефон_риелтораFROM Риелторы INNER JOIN ИНФО ON Риелторы. ID_риелтора = ИНФО.ID риелтора;Запрос «имущество за риелтором» - выводит информацию о количестве имущества закрепленного за каждым риелтором.SELECT Риелторы.ФИО_Риелтора, Count(ИНФО.тип) AS [Count-тип], Sum(ИНФО.стоимость) AS [Sum-стоимость]FROM Риелторы INNER JOIN ИНФО ON Риелторы.ID_риелтора = ИНФО.ID_риелтораGROUP BY Риелторы.ФИО_Риелтора;Запрос на копирование - выполняет копирование всех полей проданного имущества из таб. «Инфо» в таб. «Проданные».INSERT INTO Проданные ( №_договора, заявка, тип, Площадь_кв_метр, Адрес, [Этаж(ей)], Колл_комнат, стоимость, [стоимость_ аренда], ФИО_покупателя, Телефон_покупателя, ФИО_Риелтора, Телефон_риелтора )SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимость, ИНФО.[стоимость_ аренда], Покупатели.ФИО_Покупателя, Покупатели.Телефон_покупателя, Риелторы.ФИО_Риелтора, Риелторы.телефон_риелтораFROM Риелторы INNER JOIN (ИНФО INNER JOIN Покупатели ON ИНФО.№_договора=Покупатели.№_договора) ON Риелторы.ID_риелтора=ИНФО.ID_риелтораWHERE куплено=true;Запрос на удаление - удаляет данные о проданном имуществе из таб. «Инфо»DELETE ИНФО.№_договора, ИНФО.куплено, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимость, ИНФО.[стоимость_ аренда], ИНФО.ФИО_продавца, ИНФО.Телефон_Продавца, ИНФО.ID_риелтораFROM ИНФОWHERE (((ИНФО.куплено)=True));Комнат больше(меньше) - выводит поля из таб. «Инфо» по критерию.SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимостьFROM ИНФОWHERE (((ИНФО.Колл_комнат)>=(<=)[введите колличество комнат]) AND ((ИНФО.куплено)=False));площадь больше(меньше) - выводит поля из таб. «Инфо» по критерию.SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимостьFROM ИНФОWHERE (((ИНФО.Площадь_кв_метр)>= (<=) [введите площадь]) AND ((ИНФО.куплено)=False));Прибыль - выводит сумму проданного имущества из таб. «Проданные» SELECT DISTINCTROW Sum(Проданные.стоимость) AS СуммаFROM Проданные;Продано риелтором - выводит сумму проданного имущества каждым риелтором.SELECT Проданные.ФИО_Риелтора, Sum(Проданные.стоимость) AS [Sum-стоимость]FROM ПроданныеGROUP BY Проданные.ФИО_Риелтора;Проданные Запрос - выводит все поля из таб. «Проданные»SELECT Проданные.№_договора, Проданные.заявка, Проданные.тип, Проданные.Площадь_кв_метр, Проданные.Адрес, Проданные.[Этаж(ей)], Проданные.Колл_комнат, Проданные.стоимость, Проданные.[стоимость_ аренда], Проданные.ФИО_покупателя, Проданные.Телефон_покупателя, Проданные.ФИО_Риелтора, Проданные.Телефон_риелтораFROM Проданные;Сумма больше(меньше) - выводит поля из таб. «Инфо» по критерию.SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимостьFROM ИНФОWHERE (((ИНФО.стоимость)>=(<=)[введите сумму]) AND ((ИНФО.куплено)=False));Тип - выводит поля из таб. «Инфо» по критерию.SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимостьFROM ИНФОWHERE (((ИНФО.тип)=[введите тип]) AND ((ИНФО.куплено)=False));Этаж больше(меньше) - выводит поля из таб. «Инфо» по критерию.SELECT ИНФО.№_договора, ИНФО.заявка, ИНФО.тип, ИНФО.Площадь_кв_метр, ИНФО.Адрес, ИНФО.[Этаж(ей)], ИНФО.Колл_комнат, ИНФО.стоимостьFROM ИНФОWHERE (((ИНФО.[Этаж(ей)])>=(<=)[введите этаж(ей)]) AND ((ИНФО.куплено)=False));Макрос - программный объект, при обработке «развёртывающийся» в последовательность действий или команд.Макрос(Рисунки 24 и 2) - выполняет функцию поиска по номеру договора.Рисунок 24 (макрос 1) Рисунок 25(макрос 1 поле «найти запись» )
Макрос(Рисунок 26) - выполняет функцию обновления таблиц «Инфо» и «Проданные» Рисунок 26 (макрос 2) Список литературыЭлектронная встроенная гипертекстовая справочная система Microsoft Access, файл MSACC20.HLP, 4.7 МбайтЖурнал "PC Magazine Russian Edition" ?7 1999, "Microsoft Access"Бойко И., Объектно-ориентированные СУБД.- Киев: Высшая школа, 1999Майкл. Хэлволсон, Майкл Янг, Эффективная работа с Microsoft Office. C.Петербург: Питер, 2001Рыбакова О. О., Проектирование автоматизированных информационных систем. Методический материал для проведения аудиторных занятий и самостоятельной работы. Издание первое. - Запорожье: ЗЕТК, 2001ГЛАВА IIЯ проходил практику в ЦДИЮТТ Краснодарского Края на должности помощник техника. Ниже представлена схема предприятия и схема КС.Структура предприятия Директор Компьютерный класс №1Компьютерный класс №2Рабочие компьютеры на учреждении Секретарь Кадровик и Инженер Бухгалтерия МетодистыКраткая характеристика предприятияДанное предприятие (ГУДОД ЦДИЮТТ КК) осуществляет дополнительное обучение детей в возрасте от 6 до 18 лет в направлениях:1) Судомодельный.2) Начально-технического моделирования.3) Компьютерной грамотности.4) Радиотехнического конструирования.5) "Юный моряк".6)
Страницы: 1, 2
|