Проектирование базы данных информации о районах Санкт-Петербурга

Оглавление

Введение

1. Постановка задачи

1.1 Состав хранимой БД информации

1.2 Выходная информация

2. Проектирование базы данных

2.1 Определение сущностей

2.2 Построение ER-диаграммы

2.3 Получение предварительных отношений

2.4 Нормализация отношений, таблица окончательных отношений

. Создание базы данных

3.1 Создание исходных таблиц

3.2 Схема данных

3.3 Разработка запросов к базе данных

3.4 Разработка пользовательского интерфейса

Заключение

Список использованной литературы

Введение

база данные информация город интерфейс

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

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

1. Постановка задачи

1.1 Состав хранимой БД информации

Мною были определены основные объекты рассматриваемой предметной области, информация о которых должна содержаться в базе данных, и состав этой информации:

¨       Главы администрации

·        Ф.И.О.

·        Возраст

·        Год вступления в должность

¨       Органы самоуправления

·        Название

·        Район

·        Кол-во отделений полиции

¨       Районы

·        Название района

·        Население

·        Адрес органа самоуправления

·        Наличие метро

¨       Муниципальные округи

·        Название

·        Район

·        Население

1.2 Выходная информация

Создание запросов и отчётов - необходимое требование при разработке БД, которое позволит пользователям быстрее получать, отфильтровывать и просматривать полезную для них информацию.

¨       Запросы на выборку:

·        Все округи района

·        Районы с определённым населением

·        Все районы где есть метро

·        Главы администрации определённого возраста

¨       Запросы на основе связанных таблиц:

·        Вывести на экран название района, орган самоуправления, население, главу администрации и наличие метро

¨       Запросы на обновление:

·        Новая глава администрации

¨       Запрос на удаление:

·        Упразднение муниципального округа

¨       Запрос на создание таблицы:

·        5 самых заселённых районов

2. Проектирование базы данных

2.1 Определение сущностей

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

Каждая сущность должна иметь определённое количество атрибутов или свойств сущности. Они должны быть характеристиками сущности, но не должны представлять самостоятельного интереса. Главным среди них будет являться ключ сущности. В качестве ключа следует выбирать минимальный набор атрибутов, такой, что при удалении одного составляющего данного ключа весь набор переставал бы выполнять свою основную функцию (далее ключи сущностей будут подчёркнуты).

Исходя из первоначальных целей создания базы данных, необходимо выделить следующие сущности:

Главы администрации

Ф.И.О.

Возраст

Год вступления в должность

Органы самоуправления

Название

Район

Кол-во отделений полиции

Районы

Название района

Население

Адрес органа самоуправления

Муниципальные округи

Название

Район

Население

2.2 Построение ER-диаграммы

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

Связи бывают разных типов. Самая распространённая и самая простая связь - бинарная, или связь между двумя сущностями. Если сущностей три, то связь называется тернарной. В общем случае связи являются n-арными. В данной работе будут использованы исключительно бинарные связи.

Также выделяют различные степени связи:

:1 - один экземпляр одной из сущностей взаимодействует ровно с одним экземпляром другой сущности;

:n - один экземпляр одной из сущностей взаимодействует ровно с несколькими экземплярами другой сущности;

n:1 - несколько экземпляров одной сущности взаимодействуют ровно с одним экземпляром другой сущности;

n:m - один экземпляр одной из сущностей взаимодействует с несколькими экземплярами другой сущности и, в тоже время, один экземпляр второй сущности взаимодействует с несколькими экземплярами из первой сущности.

Степени связи, также как и классы принадлежности, необходимы при построении ER-диаграммы, которая изображена на рис. 1.

Рис.1. ER-диаграмма

2.3 Получение предварительных отношений

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

Первичный ключ отношений - атрибут или набор атрибутов, который может быть использован для однозначной идентификации.

Данные в БД представляются в виде отношений.

Для этого необходимо руководствоваться следующими шестью правилами для бинарных связей:

Правило 1. Если степень связи 1:1 и класс принадлежности обеих сущностей обязательный, то такая связь преобразуется в одно отношение, первичным ключом которого становится любой из сущностей.

Правило 2. Если степень связи 1:1 и класс принадлежности одной из сущностей обязательный, а другой необязательный, то формируется два отношения, по одному для каждой сущности. Ключ каждой сущности становится первичным ключом соответствующего отношения. Ключ сущности с необязательным классом принадлежности добавляется как атрибут в отношение для сущности с обязательным классом принадлежности.

Правило 3. Если степень связи 1:1 и  класс принадлежности обеих сущностей необязательный, то необходимы три отношения: по одному для каждой сущности и одно для связи. Ключами первых двух отношений будут ключи сущностей, а ключом третьего - ключ любой из сущности.

Правило 4. Если степень связи 1:n и  класс принадлежности n-связной сущности необязательный, то необходимы три отношения: по одному для каждой сущности. Ключами этих отношений станут ключи каждой сущности. Ключ односвязной сущности добавится как атрибут в отношение для n-связной сущности.

Правило 5. Если степень связи 1:n и  класс принадлежности n-связной сущности обязательный, то необходимы два отношения, по одному для каждой сущности и одно для связи. В отношении для связи среди атрибутов должны быть ключи каждой сущности.  Ключами первых двух отношений будут ключи сущностей, а ключом третьего - ключ n-связной сущности.

Правило 6. Если степень связи m:n, то необходимы три отношения: по одному для каждой сущности и одно для связи. В отношении для связи среди атрибутов должны быть ключи каждой сущности. Ключами первых двух отношений становятся ключи сущностей, а ключом третьего - ключи обеих сущностей.

В соответствии с вышеперечисленными правилами для БД формируются следующие предварительные отношения (Таблица 1).

Таблица 1.

Таблица предварительных отношений

2.4 Нормализация отношений, таблица окончательных отношений

Всего выделяют три нормальные формы и далее формы высших порядков.

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

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

Третья нормальная форма (3НФ) - отношение, находящееся в 2НФ и включающее в себя лишь взаимно независимые отношения. Это значит, что факты, хранящиеся в таблице, должны зависеть только от ключа.

Кроме вышеописанных трёх НФ, следует обратить внимание на одну из высших НФ, а именно на нормальную форму Бойса-Кодда (НФБК). Суть её состоит в том, что детерминанты всех функциональных зависимостей являются потенциальными ключами.

В соответствии с вышеперечисленными формами для БД формируются следующие окончательные отношения (Таблица 2).

Таблица 2.

Таблица окончательных отношений

3. Создание базы данных

.1 Создание исходных таблиц

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

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

Пример таблицы изображен на рисунке 2.

Рис. 2. Районы

Схема данных - это набор постоянных связей между таблицами. Она отражает исходные таблицы, связи между ними, а также все поля таблиц, включая ключевые.

Разработка схемы данных является необходимым пунктом создания БД. В данной работе для осуществления поставленных целей требуется создать схему данных (Рис.3).

Рис. 3. Схема данных

3.3 Разработка запросов к базе данных

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

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

Рассмотрим предложенные в данной работе запросы на языке SQL:

) SELECT [Муниципальные округи].Район, [Муниципальные округи].[Название муниципального округа], [Муниципальные округи].Население[Муниципальные округи]((([Муниципальные округи].Район)=[Нужный район]))BY [Муниципальные округи].Район DESC, [Муниципальные округи].[Название муниципального округа] DESC, [Муниципальные округи].Население DESC;

Выводит на экран все муниципальные округи нужного района.

2) SELECT Районы.Население, Районы.[Название района], Районы.[Адрес органа самоуправления], Районы.МетроРайоны(((Районы.Население)>[Выше кол-ва населения]))BY Районы.Население DESC;

Показывает все районы с определённым населением

3) SELECT Районы.Метро, Районы.[Название района], Районы.Население, Районы.[Адрес органа самоуправления]Районы(((Районы.Метро)=Yes));

Показывает все районы, где есть метро

SELECT [Главы администрации].Возраст, [Главы администрации].ФИО, [Главы администрации].[Год вступления в должность], [Главы администрации].Район[Главы администрации]((([Главы администрации].Возраст)>[Старше]))BY [Главы администрации].Возраст DESC;

Выводит имена глав администрации в возрасте определённого возраста

5) SELECT Районы. [Название района], [Органы самоуправления]. [Адрес органа самоуправления], Районы. Население, [Главы администрации]. ФИО, Районы. Метро[Главы администрации] INNER JOIN (Районы INNER JOIN [Органы самоуправления] ON Районы.[Название района] = [Органы самоуправления].Район) ON [Главы администрации].ФИО = [Органы самоуправления].[ФИО главы администрации];

Выводит районы, их органы самоуправления, население, глав администрации и наличие метро

6) UPDATE [Главы администрации] SET [Главы администрации].ФИО = [Введите ФИО]((([Главы администрации].Район)=[Нужный район]));

Выводит поле ввода ФИО нового главы администрации определённого района

7) DELETE [Муниципальные округи].[Название муниципального округа][Муниципальные округи]((([Муниципальные округи].[Название муниципального округа])=[Нужный Округ]));

Выводит полё ввода упразднённого округа с последующим удалением его из базы

8) SELECT Районы.[Название района], [Органы самоуправления].[Адрес органа самоуправления], Районы.Население, [Главы администрации].ФИО, Районы.Метро INTO [Район + Орган + Население + Глава + Метро]Районы INNER JOIN ([Органы самоуправления] INNER JOIN [Главы администрации] ON [Органы самоуправления].Район = [Главы администрации].[Район управления]) ON Районы.[Название района] = [Органы самоуправления].Район;

Выводит 5 самых заселённых районов

3.4 Разработка пользовательского интерфейса

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

Рис.4. Интерфейс

Заключение

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

Проектирование состояло из построения ER-диаграммы, определения ключевых полей для связи и определения правил этих связей.

Список использованной литературы

1) Попов Е.О., Павлов Н.В., Скородумов Д.Н. «Информатика. Работа в Microsoft Access», метод. указания по выполнению лабораторных работ и курсовому проектированию - СПб.: Изд-во СПбГТУ, 2008. - 94 с.

) Дуболазов В.А., Павлов Н.В. «Правила оформления курсовых проектов и работ», метод. указания - СПб.: Изд-во СПбГТУ, 2007. - 25 с.

) Павлов Н.В. «Основы работы с системой управления базами данных MS Access 97», метод. указания по выполнению лабораторных работ - СПб.: Изд-во СПбГТУ, 2001. - 68 с.