Реляционные базы данных
Реляционные базы данных
Содержание
Введение…………………………………………………………
Теоретическая часть……………………………………………………….…..
1. Понятия базы данных и системы управления базами данных…….….…...3
2. Основные понятия реляционных баз данных…………………….………..4
3. Проектирование баз данных………………………………………………...5
3.1. Инфологическое проектирование…
3.1.1. Модель «сущность-связь»……………………….…………
3.2. Логическое проектирование……………
3.3. Физическое проектирование……………
Практическая часть………………………………………….………….………
1. Постановка задачи…………………………………
2. Создание инфологической модели БД……………………………….……..9
2.1. Создание и описание сущностей……………………………………….….9
2.2. Создание связей между сущностями……………………………………..10
3. Создание логической модели БД……………………………………………11
Заключение……………………………………………………
Список литературы…………………………………
Введение
В современном мире нам приходится сталкиваться с огромным количеством информации, которую необходимо запоминать или где-то хранить. Так как человеческий мозг не может справиться с такой задачей на помощь приходят компьютеры, где самая разнообразная информация может храниться в разных форматах.
Совокупность сведений о каких-либо объектах, процессах, событиях или явлениях, организованная таким образом, чтобы можно было легко представить любую часть этой совокупности, называют базой данных. Задачи хранения, получения, анализа данных принято называть управлением данными, а программы для решения подобных задач – системами управления базами данных (СУБД).
Данная курсовая работа посвящена реляционным базам данных. "Реляционный" - Relation - обозначает взаимосвязанный. Реляционная база данных - это набор двумерных простых таблиц.
Так как на сегодняшний день практически все работающие базы данных соответствуют реляционной модели, задача данной курсовой работы состоит в рассмотрении ее основных особенностей и проектировании структуры базы данных автоматизированной информационной системы с целью приобретения практических навыков по разработке реляционной базы данных.
Основной метод, используемый в данной курсовой работе, - метод анализа и синтеза.
Теоретическая часть
1. Понятия базы данных и системы управления базами данных.
Цель любой информационной системы – обработка данных об объектах реального мира. Основные идеи современной информационной технологии базируются на концепции баз данных.
База данных (БД) - это организованное собрание данных, где данные хранятся с некоторым назначением.
Согласно данной концепции основой информационной технологии являются данные, организованные в БД, адекватно отражающие реалии действительности в той или иной предметной области и обеспечивающие пользователя актуальной информацией в соответствующей предметной области. Под предметной областью принято понимать часть реального мира, подлежащего изучению для организации управления и, в конечном счёте, автоматизации.
Первые БД появились уже на заре 1-го поколения ЭВМ представляя собой отдельные файлы данных или их простые совокупности.
Создавая базу данных, пользователь
стремится упорядочить
Структурирование - это введение соглашений о способах представления данных.
Неструктурированными называют данные, записанные, например, в текстовом файле.
По мере увеличения объемов и структурной сложности хранимой информации, а также расширения круга потребителей информации, определилась необходимость создания удобных и эффективных систем интеграции хранимых данных и управления ими. Теперь создание базы данных, ее поддержка и обеспечение доступа пользователей к ней осуществляются централизованно с помощью специального программного инструментария - системы управления базами данных (СУБД).
Система управления базами данных (СУБД) - это комплекс программных и языковых средств, необходимых для создания баз данных, поддержания их в актуальном состоянии и организации поиска в них необходимой информации.
Использование СУБД обеспечивает лучшее управление данными, более совершенную организацию файлов и более простое обращение к ним по сравнению с обычными способами хранения информации.
По характеру использования СУБД делят на персональные (СУБДП) и многопользовательские (СУБДМ). К персональным СУБД относятся VISUAL FOXPRO, ACCESS и др. К многопользовательским СУБД относятся, например, СУБД ORACLE и INFORMIX.
Операции с данными
обычно выполняют с помощью
Вывод: Таким образом, БД является важнейшей составной частью информационных систем, которые предназначены для хранения и обработки информации. Изначально такие системы существовали в письменном виде. Развитие средств вычислительной техники обеспечило возможность для создания и широкого использования автоматизированных информационных систем. Для управления данными и обеспечения эффективности доступа к ним были созданы системы управления данными.
СУБД называют программную систему,
предназначенную для создания ЭВМ
общей базы данных для множества
приложений, поддержания ее в актуальном
состоянии и обеспечения
2. Основные понятия реляционных баз данных.
Понятие реляционный (англ. relation — отношение) связано с разработками известного американского специалиста в области систем баз данных, сотрудника фирмы IBM д-ра Е. Кодда, которым впервые был применен термин «реляционная модель данных».
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:
- каждый элемент таблицы - один элемент данных;
- повторяющиеся группы отсутствуют;
- все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
- каждый столбец имеет уникальное имя;
- одинаковые строки в таблице отсутствуют;
- порядок следования строк и столбцов может быть произвольным. Таблица такого рода называется отношением.
База данных, построенная с помощью отношений, называется реляционной базой данных.
Каждому классу объектов материального мира ставится в соответствие некоторое множество атрибутов. Отдельный объект класса описывается строкой значений атрибутов. Эту строку называют кортежем. Всему классу объектов соответствует множество картежей, называемое отношением. Набор атрибутов называют схемой отношений. (Абстрагируясь от терминов, можно сказать, что отношение – это таблица, кортеж – строка таблицы, а схема отношений – шапка таблицы).
Для того чтобы таблицы можно было связать между собой, используют первичные ключи, то есть те атрибуты таблиц, которые однозначно указывают на строки. Связи между первичными ключами определяются с помощью указателей. Первичные ключи позволяют не только связать между собой разные таблицы, но и выполнить быстрый поиск данных для представления их в запросе, форме на экране или в отчете на принтере. Ключ, состоящий из нескольких полей, называют составным.
Вывод: Реляционной считается такая база данных, в которой все данные представлены для пользователя в виде прямоугольных таблиц значений данных. Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка — конкретный объект.
3. Проектирование баз данных.
Проект базы данных надо начинается с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Объединяя частные представления о содержимом базы данных, полученные в результате опроса пользователей, и свои представления о данных, которые могут потребоваться в будущих приложениях, администратор базы данных сначала создает обобщенное неформальное описание создаваемой базы данных.
3.1. Инфологическое проектирование.
Первым этапом и самым главным этапом в процессе проектирования и создания базы данных, является разработка инфологической модели. Это неформальное описание создаваемой базы данных выполняется с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных.
Такая человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. В конце концов, этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.
Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Инфологическую модель так же называют концептуальной и семантической.
Чаще всего концептуальная модель базы данных включает в себя:
- описание информационных объектов, или понятий предметной области и связей между ними.
- описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
3.1.1 Модель «сущность-связь».
Модель «сущность-связь» (ER-модель) (англ. entity-relationship model, ERM) — модель данных, позволяющая описывать концептуальные схемы предметной области. Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом.
Основные элементы ER-моделей:
- объекты (сущности);
- атрибуты объектов;
- связи между объектами.
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д.
Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей.
Связь – ассоциирование двух или более сущностей.
ER-модель используется при
Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).
ER-модель представляет собой
формальную конструкцию,
Основные преимущества ER-моделей:
- наглядность;
- модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
ER-модели реализованы во
Между двумя сущностям, например, А и В возможны четыре типа связей:
Первый тип – связь ОДИН-К-
Второй тип – связь ОДИН-КО-
Так как между двумя сущностями возможны связи в обоих направлениях, то существует ещё два типа связи МНОГИЕ-К-ОДНОМУ (М: 1) и МНОГИЕ-КО-МНОГИМ (М: М).
При установлении связи между двумя
таблицами одна из них будет являться
главной (родительской), а вторая —
подчиненной (дочерней). Различие между
ними несколько упрощенно можно
пояснить следующим образом. В главной
таблице всегда доступны все содержащиеся
в ней записи. В подчиненной
же таблице доступны только те записи,
у которых значение атрибутов
внешнего ключа совпадает со значением
соответствующих атрибутов
3.2. Логическое проектирование.
Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи. Внешний ключ появляется в дочерней сущности, он же является первичным в родительской.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован.
На этапе логического
3.3. Физическое проектирование.
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.
Вывод: Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ. При необходимости можно переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель данных.
Инфологическая модель предметной области строится первой. Предварительная инфологическая модель строится еще на предпроектной стадии и затем уточняется на более поздних стадиях проектирования. Затем на ее основе строится даталогическая модель. А уже потом и физическая.
Практическая часть
1.Постановка задачи.
В интернет-магазине создается локальная информационная система (ИС), призванная автоматизировать процесс учета сделок купли–продажи. Создаваемая система должна обеспечить ввод, хранение и поиск информации о сделках, совершенных в данном интернет магазине. Каждой сделке присваивается уникальный цифровой код. Информация о сделке должна содержать сведения о дате и времени сделки, товаре, который продается, количестве продаваемого товара, фамилии, имени, отчестве и номере паспорта клиента, а также о фамилии, инициалах и личном номере менеджера в отделе кадров, информацию о доставке, методе платежа, предоставляемой скидке. Система должна позволять вычислить денежный оборот за один или несколько дней, а также осуществлять поиск информации о сделках по номеру паспорта клиента.
Задача состоит в
2. Создание инфологической модели БД.
Первым этапом и самым главным этапом в процессе проектирования и создания базы данных, является разработка инфологической модели.
2.1. Создание и описание сущностей.
Проведем анализ предметной области с целью выделить основные сущности. Поскольку речь идет об учете сделок продажи товара, ясно в модели должна присутствовать сущности:
• СДЕЛКА (в этой сущности будет отражена
вся необходимая информация о продаже товара)
• ТОВАР (в этой сущности будет отражена информация о товаре,
его стоимости, а также месте хранения на складе)
• СКЛАД (в этой сущности будет отражена информация о
количестве товара и условии его хранения)
• КЛИЕНТ (в это сущности будет отражена информация о
клиенте, его ФИО, паспортные данные)
• МЕНЕДЖЕР (в этой сущности будет отражена информация
менеджере)
• ПЛАТЕЖ (в этой сущности будет отражена информация о
методе платежа, взымаемой комиссии)
• СКИДКА (в этой сущности будет отражена информация
предоставляемой скидке)
• ДОСТАВКА (в этой сущности будет отражена информация
способе доставки и его стоимости)
2.2. Создание связей между сущностями.
Для задания связей между указанными сущностями сначала составим описание данной предметной области при помощи ряда истинных высказываний на естественном языке.
Любой КЛИЕНТ должен совершить одну или несколько СДЕЛОК.
Каждую СДЕЛКУ должен совершать только один КЛИЕНТ.
Любой МЕНЕДЖЕР может обслуживать одну или несколько СДЕЛОК, но может не обслуживать и не одной (например, только принят на работу).
Каждую СДЕЛКУ должен обслуживать только один МЕНЕДЖЕР.
Любой ТОВАР может продаваться при разных СДЕЛКАХ.
При совершении СДЕЛКИ должна покупаться один ТОВАР.
При совершении СДЕЛКИ может предоставляться одна СКИДКА.
СКИДКА может предоставляться в нескольких СДЕЛКАХ.
При совершении СДЕЛКИ может осуществляться одна ДОСТАВКА.
ДОСТАВКА может осуществляться в нескольких СДЕЛКАХ.
При совершении СДЕЛКИ может производится один ПЛАТЕЖ.
ПЛАТЕЖ может производится в нескольких СДЕЛКАХ.
СКЛАД размещает ТОВАР.
Анализ приведенных
КЛИЕНТ совершает СДЕЛКУ.
МЕНЕДЖЕР обслуживает СДЕЛКУ.
ТОВАР продается при СДЕЛКЕ.
СКИДКА предоставляется при СДЕЛКЕ.
ПЛАТЕЖ производится при СДЕЛКЕ.
ДОСТАВКА осуществляется при СДЕЛКЕ.
СКЛАД размешает ТОВАР.
Все семь связей являются связями "один-ко-многим". В шести случаях сущность СДЕЛКА является дочерней. В одном случае сущность ТОВАР является дочерней.
Во всех связях за исключением связи, СКИДКА предоставляется при СДЕЛКЕ, родительские сущности не могут принимать пустые значения, т.к. при отсутствии экземпляра хотя бы одной из родительских сущностей экземпляр сущности СДЕЛКА перестает описывать сделку по продаже ТОВАРА.
3. Создание логической модели БД.
Теперь для каждой сущности необходимо указать первичные ключи и неключевые атрибуты. Кроме того, для некоторых, возможно, понадобится задание альтернативных ключей и инверсных входов.
Сведения о товаре должны состоять из уникального номера (idтовара), № места хранения на складе, названия товара, описания товара и его стоимости. Они и будут являться атрибутами сущности ТОВАР. Первичным ключом будет являться уникальный номер – idтовара.
Сведения о клиенте должны состоять из его фамилии, имени, отчества, номера его паспорта, почтового адреса и номера телефона.Они и будут атрибутами сущности КЛИЕНТ. Первичным ключом можно было бы выбрать номер паспорта, поскольку он однозначно идентифицирует любой из экземпляров этой сущности. Однако, номер паспорта не является числом, т.к. кроме цифр содержит и буквы, и, следовательно, для его хранения будет использоваться строка минимум из 13 символов, что не совсем удобно. Поэтому введем для каждого КЛИЕНТА уникальный номер, который и будет первичным ключом. А атрибут "номер паспорта клиента" сделаем альтернативным ключом, чтобы обеспечить возможность быстрого поиска информации о сделках по его значениям, согласно заданию.
Сведения о менеджере должны включать фамилию, инициалы, стаж работы и учетный номер менеджера – они и будут атрибутами сущности МЕНЕДЖЕР. Первичным ключом в данном случае будет учетный номер менеджера (idменеджера).
Сведения о скидке должны включать вид скидки и процентное значение. Они и будут атрибутами сущности СКИДКА. Ключевым будет атрибут idскидки, а атрибут "Вид скидки" сделаем альтернативным ключом.
Сведения о платеже должны включать метод платежа, валюту платежа, взымаемую комиссию и уникальный номер вида платежа – idплатежа, который будет являться ключевым атрибутом сущности ПЛАТЕЖ. Атрибут "Вид платежа" сделаем альтернативным ключом, а атрибут "Валюта платежа" - инверсным входом.
Сведения о доставке должны включать способ и стоимость доставки, а также уникальный номер – idдоставки, который будет являться ключевым атрибутом сущности ДОСТАВКА. Атрибут "Вид доставки" сделаем альтернативным ключом.
Сведения о складе должны содержать номер места хранения, количество товара на месте и условия хранения. Очевидно что первичным ключом этой сущности будет атрибут номера места хранения.
Что касается сущности СДЕЛКА, то часть атрибутов она унаследует от родительских сущностей и остается лишь добавить следующие: "дата сделки" и "количество товара". Очевидно, что первичным ключом, следует выбрать уникальный цифровой код сделки – № накладной. Поскольку в задании сказано, что создаваемая система должна позволять вычислить денежный оборот за один или несколько дней, полезно было бы сделать атрибут "дата сделки" инверсным входом, т.к. он довольно часто будет использоваться для доступа к данным.
После создания логической модели в Erwin логическая модель будет выглядеть, как показано на рисунке 1.
Рисунок 1. Логическая модель базы данных интернет-магазина.
Заключение
На сегодняшний день реляционные базы данных остаются самыми распространенными, благодаря своей простоте и наглядности, как в процессе создания, так и на пользовательском уровне.
Проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состоять база данных и какие атрибуты должны быть у этих отношений.
Такие базы данных имеют как достоинства такие как: очень высокая скорость поиска, высокая стабильность, обилие программного обеспечения для их поддержки и разработки, удобность для очень широкого круга задач; так и недостатки: хранение только однородной информации, сложности в добавлении новых структур и взаимоотношений.
Реляционная база данных — это такая база данных, которая воспринимается ее пользователями как множество переменных (т.е. переменных отношения, значениями которых являются отношения или, менее формально, таблицы.
Реляционная модель представляет материал только на логическом уровне и не затрагивает физический уровень.
Список литературы
- Дейт. К. Дж. Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом "Вильяме", 2005. — 1328 с.
- Избачков Ю.С., Петров В.Н., 2-е изд. - СПб.: Питер, 2006. — 656 с.
- Информатика в экономике: Учеб. пособие /Под ред. проф. Б.Е. Одинцова, проф. А.Н. Романова. – М.: Вузовский учебник, 2011. – 487 с.
- Информационные системы в экономике: Учеб. пособие /Под ред. проф. А.Н. Романова, проф. Б.Е. Одинцова – М.: Вузовский учебник, 2009. – 410 с.
- Савельев В.А. Персональный компьютер для всех. Создание и использование баз данных. – М.: Просвещение, 1991. – 248 c.
- Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных. – Спб.: КОРОНА, 2004. – 736 с.
- ru.wikipedia.org
Кладова А.В.