1. Метод структурирования

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

1.1. Даталогическая модель базы данных (ДЛМ)

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

1.2. Физическая модель БД

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

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

В настоящее время наблюдается тенденция к сокращению ра­бот на стадии физического проектирования. Иногда эти работы вообще бывают скрыты от проектировщика.

1.3. Внешняя модель

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

Если СУБД поддерживает уровень подсхем, то перед проекти­ровщиком встает задача их определения. Это тоже можно рас­сматривать как этап проектирования БД.

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

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

Использование аппарата подсхем облегчает работу пользова­теля, так как он должен знать структуру не всей базы данных, а только той ее части, которая имеет непосредственное отношение к нему; кроме того, эта структура приспособлена к его потреб­ностям.

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

1.4. Инфологическая модель предметной области.

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

2. Ход работы над базой данных

Инфологическая мо­дель предметной области строится первой. Предварительная инфологическая модель строится еще на предпроектной стадии и затем уточняется на более поздних стадиях проектирования. За­тем на ее основе строится даталогическая модель. Физическая и внешняя модели после этого могут строиться в любой последова­тельности, в том числе и параллельно.

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

В настоящее время наблюдается тенденция к сокращению ра­бот на стадии физического проектирования. Иногда эти работы вообще бывают скрыты от проектировщика.

3. Создание базы данных «Агентство недвижимости»

3.1. Создание таблиц

В рассматриваемой базе данных будет 2 таблицы: Риэлтеры и Продажи.

3.1.1. Создание таблицы «Риэлтеры»

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

Всего в агентстве работают 5 риэлтеров. Следовательно, в таблицу Риэлтеры занесено 5 записей:

3.1.2. Создание таблицы «Продажи»

В таблице Продажи хранятся данные обо всех проданный квартирах: номер продажи, кем продана, дата продажи и цена. Ключевым полем задано поле НомерПродажи, имеющее тип Счетчик. Поле КемПродана имеет Числовой тип, поля ДатаПродажи – тип Дата/время, а поле Цена – Денежный.

Имеются сведения о 10 продажах. Поэтому таблица Продажи содержит 10 записей:

3.2. Создание связей между таблицами

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

3.3. Создание запросов

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

3.3.1. Создание запроса «Продажи в сентябре 2004 г.»

В режиме Конструктора создадим простой запрос. Добавим в бланк запроса поля НомерПродажи, ДатаПродажи и Цена из таблицы Продажи и поля ФИО и Телефон из таблицы Риэлтеры. Для поля Дата зададим Условие отбора с 01.09.2004 по 30.09.2004. В результате Конструктор запроса примет вид:

Выполнив созданный запрос, получим:

3.2. Создание запроса «Расчет суммы продаж, выполненных каждым риэлтером»

Для начала создадим простой запрос, содержащий поле ФИО из таблицы Риэлтеры, поля ДатаПродажи и Цена из таблицы Продажи. Сохраним только что созданный запрос, присвоив ему имя ВсеПродажи. Выполнив этот запрос, получим следующий набор данных:

Теперь по только что созданному простому запросу создадим перекрестный запрос, нажав Создать на вкладке Запросы главного окна базы данных и выбрав Перекрестный запрос. На первом шаге запустившегося мастера, выберем только что созданный простой запрос. Для заголовков строк выберем поле ФИО. Для заголовков столбцов – ДатаПродажи. В качестве интервала группировки данных выбираем Дата. Зададим функцию Сумма для поля Цена. Запустив созданный запрос, получим:

3.3. Создание отчетов

Отчет является эффективным средством представления данных в печатном формате. Имея возможность управлять размером и внешним видом всех элементов отчета, пользователь может отобразить сведения желаемым образом.

Большинство отчетов являются присоединенными к одной или нескольким таблицам и запросам из базы данных. Источником записей отчета являются поля в базовых таблицах и запросах. Отчет не должен включать все поля из каждой таблицы или запроса, на основе которых он создается.

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

3.3.1. Создание отчета «Риэлтеры»

Создадим отчёт, который будет выводить данные о риэлтерах в удобном для печати виде. В главном окне базы данных перейдем на вкладку Отчеты и выберем Создание отчета с помощью мастера. В качестве источника данных для отчета выберем таблицу Риэлтеры и выберем из нее все поля. Уровни группировки добавлять не будем. Зададим сортировку записей по возрастанию данных поля ИндивидуальныйНомер. Макет – табличный. Стиль – полужирный. Сохраним созданный отчет. Созданный отчет будет выглядеть следующим образом:

                                       Риэлтеры

ИндивидуальныйНоиер                    ФИО                          Телефон

          1                           Иванов Иван Иванович           11-11-11

          2                           Петров Петр Петрович            22-22-22

          3                           Сидорова Валентина               33-33-33

          4                           Кудинова Нина Павловна         44-44-44

          5                           Купцов Дмитрий Николаевич     55-55-55

3.3.2. Создание отчета «По суммам продаж, выполненных каждым риэлтером»

Создадим отчет, который выведет на печать, данный, полученные при выполнении ранее созданного одноименного запроса.

При первоначальном запуске Мастера отчетов в качестве источника данных выберем ранее созданный одноименный запрос.

Выберем все доступные поля из названного запроса. Уровни группировки не задаем.  Упорядочим выводим данные поля ФИО по алфавиту. Макет – табличный.

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

3.3.3. Создание отчета «Продажи сентября 2004 года»

Этот отчет построим на основе ранее созданного одноименного запроса, выбрав все доступные поля. Уровни группировки не добавляем. Зададим упорядочивание по возрастанию для поля НомерПродажи. Макет выберем табличный. Стиль – деловой.

                                       Продажи

НомерПродажи  ДатаПродажи   ФИО                     Телефон                Цена

                 1               01.09.2004   Иванов Иван Иванович   11-11-11           1 500 000,00р.

                 2               05.09.2004   Петров Петр Петрович    22-22-22           3 500 000,00р.

                 3               10.09.2004   Кудинова Нина Павловна 44-44-44           1 000 000,00р.

                 4               14.09.2004   Купцов Дмитрий           55-55-55           2 350 000,00р.

                                               Николаевич

                 5               21.09.2004   Сидорова Валентина      33-33-33           1 750 000,00р.

                                               Семеновна

                 6               24.09.2004   Кудинова Нина Павловна 44-44-44           3 765 000,00р.