База данных "Телефонный справочник"

РОССИЙСКИЙ  ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИННОВАЦИОННЫХ ТЕХНОЛОГИЙ И ПРЕДПРИНИМАТЕЛЬСТВА

ПЕНЗЕНСКИЙ  ФИЛИАЛ

Кафедра «Информационные системы»

 

 

 

 

 

 

Курсовой проект

по дисциплине: «Управление Данными»

на тему: «Телефонный справочник»

 

 

 

Выполнил: студент гр. 10и1 Тарасов С. Г.

Проверил: преподаватель Корниенко К. А.

 

 

 

Пенза 2013 г.

Утверждаю

Зав. кафедры 

____________

Дисциплина - Управление данными.

Задание на курсовое проектирование.

 

 

Выдано студенту гр.______10и1___                Ф.И.О._Тарасов С. Г.

Вариант задания №______33______           Дата выдачи_________________

Руководитель ___________________          Студент_____________________

 

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

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

Далее следует провести нормализацию концептуальной схемы до второй или  третьей нормальной формы и на их основе создать проект БД в среде Access и провести его отладку и  тестирование.

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

Содержание

Введение.………………………………………………………………….………...4

1 Общие понятия и определения…………………………………………….…….5

2 Анализ заданной предметной  области, потребности различных  категорий пользователей разрабатываемой  БД……………………………………..………..8

3 Разработка и описание концептуальной схемы и подсхем БД ..…..………….9

4 ER-Win ………………………………………………………….………….……14

5  Преобразование схемы и подсхем в реляционную БД………..……..………19

6 Нормализация реляционной БД…………………...………………….…..……21

1НФ…………………………………………………………………………….…..21

2НФ…………………………………………………………………………….…..21

3НФ…………………...………………………………………………………..…..22 7 Разработка запросов в SQL………….……………………………………….…23

8 Объединение компонентов базы данных в единое приложение…………….27

Заключение  ………………………………………………………………….…….29

Список литературы ………………………………………………………….……30

 

 

 

 

 

 

 

 

Введение

  Данная курсовая работа выполнена в СУБД  Microsoft Access, входящее в прикладной пакет Microsoft Office. Созданная программа обладает рядом достоинств :

1. Легкий способ ввода или удаления.
2. Удобный дизайн программы с понятным интерфейсом и оригинальными кнопочными формами
3. Возможность просмотра или вывода на печать отчётов, наглядно демонстрирующих информацию по основным категориям
4. Наличие подробного описания предназначения и работы программы
5. Автоматизация необходимых расчетов.

 

1. Общие понятия и определения

 

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

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

Информационная система (information system) — это приложение, предназначенное для хранения и обработки данных. Основой информационной системы является база данных с информацией, хранящейся в одной или нескольких связанных таблицах.

База данных {data base) представляет собой совокупность связанных таблиц (в предельном случае - одну таблицу), предназначенных для хранения определенной информации. Термином "база данных" часто называют приложение, использующее базу данных и обладающее интерфейсом просмотра и правки, а также средствами   обработки хранящейся в базе данных информации. Однако такое приложение лучше называть информационной системой.

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

Реляционная модель (relational model). Основными элементами реляционной модели являются таблицы, представляющие сущности, в которых столбцы представляют атрибуты сущностей, а строки описывают экземпляры сущностей. Модель данных также подразумевает наличие операторов для генерации новых таблиц на основе существующих (называемых запросами (query)), именно таким способом' пользователи могут манипулировать данными и получать необходимую информацию.

Сущность (entity) —множество однотипных объектов, называемых экземплярами (instance). Каждый экземпляр характеризуется набором свойств, называемых атрибутами сущности (attribute). Каждый экземпляр индивидуален и отличается от всех остальных экземпляров во множестве.

Таблица (table) - множество ячеек с данными, образующих строки и столбцы прямоугольной таблицы. Таблица реализует сущность в понятии реляционной модели данных. Строки таблицы представляют экземпляры сущности и называются записями (records). Столбцы таблицы представляют атрибуты сущности и называются полями (fields).

Атрибут* (attribute) представляет собой определенное свойство (характеристику) данной сущности. Рекомендуется в качестве атрибутов выделять атомарные свойства сущности.

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

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

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

Ключевое поле (key field) — поле, представляющее первичный ключ или являющееся частью составного первичного ключа.

Альтернативный  ключ (alternative key) — обычные поля или комбинации атрибутов, отличающиеся от первичного ключа сущности, но также претендующие на эту роль.

Связь (relationship) - это логическое отношение между сущностями, выражающее некоторое ограничение или правило. В реляционной модели вводится понятие реляционной связи (relation) — это связь между записями, основанная на совпадении (или ином предикате) значений атрибутов, по которым устанавливается связь.

Основные  объекты Access - таблицы, формы, запросы, отчеты, макросы, модули. Таблица является основой БД, в ней хранится вся информация.

Процесс создания отдельной таблицы в составе  БД состоит из следующих этапов:

1) Создание структуры таблицы  (задание имен и типов полей,  задание ключевого поля);

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

3) Сохранить схему данных, закрыть  окно.                                                 

2. Анализ заданной предметной области, потребности различных категорий пользователей разрабатываемой БД

 

         База данных «Телефонный справочник» предназначена, прежде всего, для отображения данных об абонентах телефонной сети. С помощью данной базы данных можно получать различную информацию об абонентах, такие как город проживания, телефон, код клиента, ФИО клиента, время разговора, переговоры с конкретным пунктом, ставку, льготы и сумма оплаты. С помощью удобно оформленных запросов можно получить всю информацию о клиенте введя лишь его фамилию или телефон. Также база данных предоставляет подробный отчет об использовании сети абонентами.

 

Для более эффективной обработки  данных исходная схема разбита на несколько более мелких. Каждая часть охватывает некоторую смысловую область исходной схемы. Эти части имеют общее поле «код клиента», по которому осуществляется связь между отдельными подсхемами.

 

 

 

 

 

 

 

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

 

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

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

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

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

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

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

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

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

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

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

Схема базы данных

 

 

Рис. 1 – Схема  БД.

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

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

Второй тип - связь “один ко многим”, наиболее часто используется это  отношение. В данном случае одной записи главной таблице могут соответствовать несколько записей подчиненной таблицы. Различают две разновидности связи “один ко многим”. В первом случае предъявляются жесткие требования на обязательное наличие записей во вторичной таблице. Во втором случае такие требования отсутствуют.

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