Разработка базы данных 'Сеть ресторанов'

Министерство образования и науки Республики Казахстан

Карагандинский государственный университет им. Е.А. Букетова

Факультет математики и информационных технологий

Кафедра прикладной математики и информатики

Контрольная работа

по дисциплине Теория баз данных

на тему: Разработка базы данных "Сеть ресторанов"

Выполнила: студ. гр. Инф-308

Кудинова Ольга

Научный руководитель: ст. преп. кафедры МПИ

Смирнова М.А.

Караганда 2013

Содержание

Введение

Глава 1. Моделирование базы данных

1.1 Инфологическое моделирование

1.2 Даталогическое моделирование

2. СУБД

2.1 Анализ программно-аппаратной платформы и выбор СУБД

Заключение

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

Введение

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

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

Задача данной курсовой работы:

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

создать базу данных "Сеть ресторанов";

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

Требования к базе данных:

эффективная структура, улучшающая доступ к информации и качество сервиса;

расширяемость (возможность добавления новых данных);

проверка новых данных на предмет совпадения в имеющимися данными для исключения повторов;

защита базы данных от несанкционированного доступа к данным;

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

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

Курсовая работа состоит из трех разделов:

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

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

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

Курсовая работа завершается выводами о проектировании и создании базы данных и результатах ее проверки на разработанном контрольном примере.

Глава 1. Моделирование базы данных

1.1 Инфологическое моделирование

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

Предметная область - часть реального мира, подлежащая изучению с целью организации управления и автоматизации [1 - с.8].

В ходе анализа предметной области необходимо:

·        уяснить и указать назначение базы данных;

·        определить и выделить первоначальный набор сущностей и атрибутов предметной области.

Рассмотрим пример проектирования базы данных предметной области "Сеть ресторанов".

Назначение и предметная область

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

·        прием заказов на основе составленного меню, обслуживание клиентов;

·        бухгалтерия - расчет доходов по принятым заказам, начисление заработной платы сотрудникам;

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

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

)        Сущности.

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

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

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

Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Не стоит также использовать в качестве ключа не номер блюда, а его название, например, "Цезарь с лососем" или "Окрошка мясная по-домашнему".

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

Теперь о внешних ключах:

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

Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

В реляционной базе данных сущности представлены в виде таблиц.

В рассматриваемой информационной системе сущностями являются: Список заведений, Раздел, Сотрудники, Меню, Заказы.

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

)        Атрибуты.

Атрибут - свойство сущности в данной предметной области. Названия атрибутов одной сущности должны быть различны.

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

Атрибуты сущности Список заведений:

Атрибуты сущности Разделы:

Атрибуты сущности Сотрудники:

Атрибуты сущности Меню:

Атрибуты сущности Заказы:

)        Связи.

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

Различают следующие виды связей:

·        Взаимосвязь "один-к-одному" означает, что каждой записи в одном объекте может соответствовать только одна запись в другом объекте и обозначается одинарными стрелками между объектами.

·        Взаимосвязь "один-ко-многим" свидетельствует о том, что одной записи в одном объекте может соответствовать несколько записей в другом объекте и обозначается с помощью одинарной стрелки в одном направлении и двойной стрелки в другом направлении.

·        Взаимосвязь "многие-ко-многим" свидетельствует о том, что одной записи в одном объекте может соответствовать несколько записей в другом объекте и наоборот, обозначается такая связь с помощью двойной стрелки в одном направлении и двойной стрелки в другом направлении.

Тип отношения в создаваемой связи зависит от способа определения связываемых полей:

)        отношение "один-ко-многим" создается в том случае, когда только одно из полей является полем первичного ключа или уникального индекса

2)      отношение "один-к-одному" создается в том случае, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.

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

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

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

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

Существует три типа первичных ключей: ключевые поля счетчика (счетчик), простой ключ и составной ключ.

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

Простой ключ. Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как первичный ключ. В качестве ключа можно определить любое поле, содержащее данные, если это поле не содержит повторяющиеся значения или значения Null.

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

Логическая модель отражает структуру базы данных в виде блок-схемы связи сущностей. Такая блок-схема называется ER-диаграммой (от. англ. entity - сущность, relationship - отношение).

Модель "сущность-связь" была предложена Питером Ченом (Peter Chen) в 1976 году, в качестве унифицированного способа описания предметной области. Как самостоятельная модель данных она развития не получила, но стала основой для создания инфологических моделей БД [1 - c.32].

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

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

Нормализация - это процесс приведения структуры реляционных отношений к форме, обладающей лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Кроме задачи более эффективного использования памяти, нормализация позволяет снизить угрозу нарушения целостности базы данных из-за появления в ней внутренних противоречий [1 - c.63].

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

Пусть R - реляционное отношение, а X и Y - некоторые подмножества атрибутов этого отношения. Y функционально зависимо от X тогда и только тогда, когда для каждого значения множества X существует только одно значение множества Y. Иначе говоря, если два кортежа отношения совпадают по значению X, то они обязательно будут совпадать и по значению Y. Записывается функциональная зависимость (ФЗ) как X→Y, читается как "X функционально определяет Y". Если существует ФЗ X→Y, то X называют детерминантом, а Y - зависимой частью.

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

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

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

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

При описании 2НФ и 3НФ везде, кроме случаев, где это указано явно, предполагается, что реляционные отношения имеют только один потенциальный ключ.

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

Процесс разбиения отношения R{A,B,C} на два отношения R1{A,B}, R2{A,C} называется проецированием, а отношения R1 и R2 - проекциями. Здесь А, В и С - это некоторые непересекающиеся подмножества атрибутов исходного отношения, объединение которых даст все множество атрибутов. Если была произведена декомпозиция без потерь, то соединение проекций R1 и R2 должно дать исходное отношение R.

Отношение находится в третьей нормальной форме (ЗНФ), если оно удовлетворяет определению 2НФ и ни один из его неключевых атрибутов не зависит функционально от любого другого неключевого атрибута.

Нужно отметить, что если существует ФЗ между неключевыми атрибутами, а детерминант этой ФЗ будет, в свою очередь, зависеть от первичного ключа, мы получим транзитивную ФЗ. Иными словами, если в отношении есть только один потенциальный ключ и можно выделить транзитивные ФЗ, то это указывает, что отношение не соответствует ЗНФ.

Поскольку все отношения имеют простые ключи, то они автоматически находятся во 2 нормальной форме.

Поскольку во всех отношениях не имеют места транзитивные зависимости, то они находятся в 3 нормальной форме. Например, отношение Меню находится в 3 нормальной форме т.к. все его неключевые поля: Название, Цена, Код заведения, Код раздела полно зависят от ключевого атрибута Код блюда. Аналогично для всех других отношений.

Таким образом, отношения находятся в 3 нормальной форме.

1.2 Даталогическое моделирование

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

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

Таблица 1. Список заведений

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

Важнейшими ограничениями целостности данных являются:

·        целостность отношений;

·        ссылочная целостность.

Ограничение целостности отношений заключается в следующем. Кортежи отношения представляют в базе данных элементы определенных объектов реального мира или отношений [2 - c.48].

Например, строка таблицы Список заведений (Таблица 1) представляет конкретное заведение. Первичный ключ таблицы однозначно определяет каждый кортеж и, следовательно, каждый элемент отношения.

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

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

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

Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД.

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

база атрибут связь модель

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

Каскадное удаление состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи [2 - c.49-50].

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

2. СУБД

2.1 Анализ программно-аппаратной платформы и выбор СУБД

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

Основные функции СУБД:

·        управление данными во внешней памяти (на дисках);

·        управление данными в оперативной памяти;

·        журнализация изменений и восстановление базы данных после сбоев;

·        поддержание языков баз данных (язык определения данных, язык манипулирования данными).

В настоящее время насчитывается более 50 типов СУБД для персональных компьютеров.

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

·        характер изучаемой информационной системы предполагает не слишком большой размер базы данных;

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

·        количество пользователей предполагает наличие в одном ресторане не одного, а нескольких компьютеров, которым требуется соответствующее программное обеспечение, к тому же рассматривается не один ресторан, а сеть ресторанов. Следовательно нужно либо бесплатное ПО, либо не слишком дорогое в покупке и обслуживании, а так же не сложно в настройке (из расчета стоимости услуг специалистов в случае возникновения неполадок);

·        в настоящее время широко распространена платформа Windows, допустим, что и в компьютерах сети ресторанов тоже используется она;

·        любая база данных должна быть защищена от несанкционированного доступа, но так как у нас не база данных Пентагона, достаточно настройки доступа через пароль;

Исходя из вышеперечисленных требований, проведем анализ наиболее востребованных в настоящее время СУБД: MS Excel, MS Access 2007, MS SQL, MySQL, Oracle.

Таблица 2. Сравнительный анализ

Исходя из анализа данных о различных СУБД и учитывая решаемую задачу, для реализации базы данных "Ресторан" выбирается СУБД MS Access 2007.

Первая версия MS Access была создана в 1993 г. фирмой Microsoft.Access - это функционально полная реляционная СУБД, работающая в среде Windows. Access позволяет создавать сложные базы данных, определяя структуру таблиц, связи между ними. Access обладает совершенной системой создания запросов, отчетов и форм любой сложности. В Access, как любом приложении Windows, можно использовать все возможности обмена данными между приложениями (DDE и OLE), что позволяет включить в базу данных графическую и (или) звуковую информацию.

В Access база данных включает в себя все объекты, связанные с хранимыми данными (таблицы, формы, отчеты, запросы, макросы, модули). Все объекты Access хранятся в одном файле с расширением. mdb. В таблицах хранятся данные, которые можно просматривать, редактировать, добавлять. Используя формы, можно выводить данные на экран в удобном виде, просматривать и изменять их. Запросы позволяют быстро выбирать необходимую информацию из таблиц. С помощью отчетов можно создавать различные виды документов для вывода на печать. макросы и модули позволяют автоматизировать работу с базой данных.

Начало работы.

При запуске MS Access создаем базу данных, нажав на кнопку "Новая база данных", задаем имя файла, а также путь к папке, в которой сохраняем базу данных. Чтобы реализовать базу данных, в СУБД Access надо ввести через режим конструктора свою модель (Рисунок 3). Для начала надо ввести названия таблиц и всех их атрибуты. При вводе атрибутов надо задать тип данных и первичный ключ.

Рисунок 3. Создание таблиц в режиме Конструктор

Аналогичным образом создаем таблицы

Заключение

В современном мире часто приходится работать с данными из разных источников, каждый из которых связан с определённым видом деятельности. Для координации всех этих данных необходимы определённые знания и организационные навыки. MS Access объединяет сведения из разных источников в одной реляционной базе данных. Удобный интерфейс позволяет легко ориентироваться в ней, привлекая тем самым многих разработчиков и пользователей баз данных.

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

Разработанная база данных проста в применении и может быть использована в любом ресторане.

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

1.      Нестеров С.А. Базы данных: учеб. пособие/ С.А. Нестеров. - СПб.: Изд-во Политехн. ун-та, 2013. - 150 с.

.        Глушков СВ., Ломотько Д.В. Базы данных: Учебный курс. - Харьков: Фолно; М.: "Издательство ACT", 2003.

.        Карпова Т.С. Базы данных: модели, разработка, реализация. - СПб: Питер, 2002.

.        Крёнке Д. Теория и практика построения баз данных. - СПб: Питер, 2003.