Основы построения баз данных

Размещено на http://www.allbest.ru/

1

Федеральное агентство по образованию Российской Федерации

Министерство образования Республики Таджикистан

Российско-Таджикский (Славянский) Университет

Экономический факультет

Кафедра “Информатики и информационных систем”

Курсовая работа

По дисциплине “Базы данных”

Тема: “Основы построения баз данных”

Душанбе 2010

Содержание

Введение

1. Общие сведения

2. Общие сведения о проектировании БД

3. Классификации БД

4. Построение БД

4.1 Построение концептуальной модели

4.2 Построение реляционной модели

4.3 Нормализация

4.4 Проектирование базы данных в ACCESS

4.5 Создание SQL запросов

Заключение

Литература

Приложение

Введение

Базой данных является представленная в объективной форме совокупность самостоятельных материалов (статей, расчетов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ)

Другие определения из авторитетных монографий и стандартов:

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

База данных - совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.

База данных - некоторый набор перманентных (постоянно хранимых) данных, используемых прикладными программными системами какого-либо предприятия.

База данных - совокупность взаимосвязанных данных, совместно хранимых в одном или нескольких компьютерных файлах.

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

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

1. База данных хранится и обрабатывается в вычислительной системе.

Таким образом, любые некомпьютерные хранилища информации (архивы, библиотеки, картотеки и т.п.) базами данных не являются.

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

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

3. База данных включает метаданные, описывающие логическую структуру БД в формальном виде (в соответствии с некоторой метамоделью).

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

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

1. Общие сведения

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

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

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

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

СУБД Microsoft Access работает с БД которые хранятся в файлах с расширением mbd. Кроме самих данных в них хранятся элементы интерфейса и дополнительные модули обработки информации.

2. Общие сведения о проектировании БД

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

Таким образом, выделяются следующие четыре этапа проектирования:

1. обследование ПО, формирование и анализ требований;

2. инфологическое проектирование;

3. логическое проектирование;

4. внутреннее (физическое) проектирование.

Каждому из этапов соответствуют свои принципы, методы, приемы.

Основное содержание первого этапа:

- сбор сведений о сущностях, их свойствах и взаимоотношениях в ПО;

- о процедурах, связанных с объектами ПО;

- о требованиях по объемам информации в БД, быстродействию, пользователях и т.п.

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

На этапе концептуального, инфологического проектирования разрабатывается концептуальная схема БД. Главные проблемы заключаются в структуризации информационной анархии, полученной в результате сбора информации о ПО, в решении вопросов:

· объединения информации из различных фрагментов ПО;

· выделения объектов группировкой атрибутов (при этом семантические связи разделяются на внутренние, между атрибутами в составе объектов, и внешние - между сущностями);

· выбора ключей;

· учета и отображения в составе связей структурных и запросных связей.

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

Существуют два подхода к ПО:

· исторически первый (как более простой и быстрый) основан на интегрировании представлений о ПО пользователей информации;

· второй базируется на представлениях об объективно (независимо от пользователей) существующей ПО, с присущей ей семантикой.

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

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

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

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

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

3. Классификации БД

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

Укажем только основные классификации.

Классификация БД по модели данных:

Примеры:

· иерархические,

· сетевые,

· реляционные,

· объектные,

· объектно-ориентированные,

· объектно-реляционные.

Классификация БД по технологии физического хранения:

· БД во вторичной памяти (традиционные);

· БД в оперативной памяти (in-memory databases);

· БД в третичной памяти (tertiary databases).

Классификация БД по содержимому:

Примеры:

· Географические

· Исторические

· Научные

· Мультимедийные.

Классификация БД по степени распределённости:

· централизованные (сосредоточенные) и

· распределённые.

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

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

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

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

В реляционной БД используются четыре основных типов полей:

· Числовой,

· Символьный (слова, тексты, коды и т.д.),

· Дата (календарные даты в форме «день/месяц/год»),

· Логический (принимает два значения: «да» - «нет» или «истина» - «ложь»).

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

Системы управления базами данных позволяют объединять большие объемы информации и обрабатывать их, сортировать, делать выборки по определенным критериям и т.п.

4. Построение БД

4.1 Построение концептуальной модели

база концептуальный ключ реляционный запрос

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

1. Сущности. Это элементы реального мира, которые могут существовать независимо. В нашем примере сущностями являются: проект, детали, поставщики, заказ, служащие. Сущность представляется в концептуальной модели прямоугольником, в котором указано её имя.

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

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

Рисунок 4.1 - Концептуальная модель

4.2 Построение реляционной модели

В реляционной базе данных все данные хранятся в таблицах. Названия сущностей станут заголовками таблиц, а атрибуты станут столбцами. Целостность данных в реляционной базе данных основывается на концепции ключей. Первичный ключ (PK) - это атрибут который можно использовать для уникальной идентификации таблицы. Так у таблицы “поставщики” - ключом станет идентификационный номер поставщика, мы обозначили как “id_P”; у таблицы “детали” - номер детали мы обозначили как “id_D”, у таблицы “проект” - номер проекта мы обозначили как “id_R”, таблица “служащие” мы обозначили как “id_S”, а таблица “заказ” - номер заказа мы обозначили как “id_Z”. Внешний ключ (FK) - это атрибут, который существует в нескольких таблицах и является первичным ключом одной из этих таблиц. Связь проводим от первичного ключа одой таблицы до внешнего ключа другой таблицы.

4.3 Нормализация

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

Первая нормальная форма требует, чтобы все значения полей были атомарными и все записи уникальными. Реляционная модель, представленная на рисунке 3.1, находится в первой нормальной форме.

Модель находится во второй нормальной форме, если она, во-первых, находиться в первой нормальной форме; и, во-вторых, не содержит не ключевых атрибутов, находящихся в частичной функциональной зависимости от первичного ключа. Исходя из определения, разбиваем таблицу “поставщики” на две таблицы, вторую образовавшеюся таблицу назовем “данные поставщика”. В таблице “поставщики” у нас остался только один идентификатор “идентификационный номер поставщика”, значит не ключевые атрибуты зависят от всего первичного ключа. В таблице “данные поставщика” нет не ключевых атрибутов, значит частичной зависимости быть не может. Таким же образом разбиваем таблицы “детали”, “проект”, “служащие”, и “заказ”. Реляционная модель во второй нормальной форме представлена на рисунке 4.2.

Модель находится в третьей нормальной форме, если она находится во второй нормальной форме и не имеет транзитивных зависимостей.

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

Рисунок 4.2 - Вторая нормальная форма

Рисунок 4.3 - Третья нормальная форма

4.4 Проектирование базы данных в ACCESS

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

Затем реализуем реляционную модель третей нормальной формы в схеме данных.

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

В результате на экран выведутся те поля, которые были указаны в запросе.

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

4.5 Создание SQL запросов

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

Чтобы войти в режим SQL в Access нужно в поле конструктора запроса нажать правой кнопкой и в появившемся окне нажать “Режим SQL”.

В появившемся окне прописываем SQL запрос. К примеру, нам надо показать какие данные находятся в таблице “Заказ”. Прописываем:

SELECT Заказ.id_z, Заказ.id_d, Заказ.id_s

FROM Заказ;

В итоге появится таблица “Заказ” в которой мы видим “номер заказа”, “номер деталей”, “номера служащих” и их содержимое.

Если нам надо в таблице “Детали” упорядочить “маркировку деталей” по возрастанию, то в окне SQL. Прописываем:

SELECT Детали.Название, Детали.Размер, Детали.Маркировка

FROM Детали

ORDER BY Детали.Маркировка;

В итоге появится таблица “Детали” в которой мы видим, что в графе “Маркировка” все поля упорядочены по возрастанию.

Если нам надо выяснить какие проекты были изготовлены с 01.01.93 по 01.01.95, то в окне SQL. Прописываем:

SELECT Проект.Название, Проект.id_r, Проект.[Дата Изготовления]

FROM Проект

WHERE (((Проект.[Дата Изготовления])>"01.01.92"));

В итоге появится таблица “Проект” в которой мы увидим, что в нем находятся проекты которые были изготовлены с 01.01.93 по 01.01.95

Если нам надо выяснить всех поставщиков на букву “М” то в окне SQL. Прописываем:

SELECT Поставщик.[Ф И О], Поставщик.id_p, Поставщик.Адрес

FROM Поставщик

WHERE (((Поставщик.[Ф И О]) Like "М*"));

То в итоге мы получим таблицу “Поставщики” где будут все поставщики начинающееся на букву “М”.

Если нам надо выяснить данные поставщика, то в окне SQL. Прописываем:

SELECT [Данные поставщика].*

FROM [Данные поставщика];

То в итоги мы получим таблицу “Данные поставщика” где мы увидим идентификационный номер поставщика и его номер ИНН.

Заключение

В этой курсовой работе я провел исследование основ построения БД, рассмотрел общие сведения о базах данных и выполнил задание по составлению базы данных “Налогоплательщики”.

Литература

1. Кабилов М.М., Хасанов Ю.Х. Практикум по изучению СУБД MS Access. - Душанбе: РТСУ, 2006.

2. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. Учебник для вузов. ? Корона-Принт, 2004.

3. Вікіпедія [Електронний ресурс]. - Режим доступу: http://ru.wikipedia.org

Приложение

Задание 17. Создать БД некоторой налоговой инспекции по учету налоговых деклараций физических лиц.

1. БД организовать в виде следующих таблиц:

¦ «Налогоплательщики», включающей данные о налогоплательщике: название (для юридического лица) или ФИО (для физического лица), юридический статус(физическое лицо, государственное предприятие, ИЧП, ООО, АОЗТ и т.д.), адреса, телефоны и др. сведения;

¦ «Источник дохода», включая сведения об организации (частного лица), от которой получен доход;

¦ «Доходы», содержащей код налогоплательщика, код источника дохода, год получения, месяц получения, величину дохода, величину выплаченного налога с этого дохода.

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

3. Создать с обеспечением целостности данных Схему БД.

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

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

6. Создать запрос на отображение общих сумм доходов каждого налогоплательщика.

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

8. Создать форму по данным таблиц «Налогоплательщики» и «Источник дохода».

9. Создать форму по таблице «Налогоплательщики», добавив в нее кнопки для перехода между записями.

10. Создать отчет по первому запросу, добавив в область примечаний фамилию и группу составившего отчета.

Ход выполнения задания представлен в скриншотах:

Рисунок 1. ? Создание новой базы данных

Рисунок 2. ? Создание новой таблицы



Рисунок 3. ? Ввод данных в таблицу



Рисунок 4. ? Аналогично создание и заполнение остальных таблиц

Рисунок 5. ? Готовая таблица “Источник дохода”



Рисунок 6. ? Запрос на данные о доходах

Рисунок 7. ? Параметрический запрос



Рисунок 8. ? Запрос на итоговую сумму доходов

Рисунок 9. ? Форма Налогоплательщики



Рисунок 10. ? Форма Источник дохода

Рисунок 11. ? Отчет

Размещено на Allbest.ru