База Данных Ресторан Курсовая Работа
База Данных Ресторан Курсовая Работа
Информационное обеспечение, программирование
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!
.1
Этапы и основные принципы проектирования баз данных
.2
Структурный подход при разработке инфологической модели
.1
Классификация и сравнительная характеристика СУБД
.Даталогическая
(реляционная) модель БД
В данной курсовой работе рассматривается создание базы данных
ресторана, рассчитанной на работу с клиентами и ведение учета продуктов
приготовления, а также для обеспечения порядка в и выполнения всех заданий
поставленных исполняющему персоналу.
База данных - это единое, вместительное хранилище
разнообразных данных и описаний их структур, которое после своего определения,
осуществляемого отдельно и независимо от приложений, используется одновременно
многими приложениями.
Кроме данных база данных может содержать средства,
позволяющие каждому из пользователей оперировать только теми данными, которые
входят в его компетенцию. В результате взаимодействия данных, содержащихся в
базе, с методами, доступными конкретным пользователям, образуется информация,
которую они потребляют и на основании которой в пределах собственной
компетенции производят ввод и редактирование данных.
С ростом численности ресторанов стремительно усиливается и
конкуренция, что неизбежно приводит к необходимости эффективно и рационально
использовать имеющиеся ресурсы. В этих условиях для успешного ведения бизнеса
необходимо инвестировать в средства и инструменты его поддержания и развития.
Один из основных инструментов развития ресторанного бизнеса - это современная
база данных ресторанов.
База данных ресторана или Современная система автоматизации
ресторана - это профессиональная система управления рестораном,
многофункциональная и легко модернизируемая. Целью автоматизации является
повышение эффективности управления рестораном, ускорение обслуживания и
минимизация возможных злоупотреблений, особенно воровства. Значительная доля
успеха складывается из отличного сервиса и оперативной работы персонала. Именно
возможности автоматизации ресторана позволяют оптимально сочетать скорость и
качество.
Очевидны неоспоримые преимущества автоматизированного
ресторана перед другими подобными заведениями:
· высокое качество сервиса и скорость обслуживания
клиентов;
· абсолютный контроль всех
процессов от момента приема заказа до его исполнения;
Специализированный комплекс программного обеспечения и
оборудования для автоматизации ресторанов на порядок расширяет возможности
управления ресторанным бизнесом:
· автоматизация позволяет внедрять маркетинговые и
учетные политики нового поколения и всегда иметь достоверную информацию о
работе заведения;
· четко зафиксировав
обязанности и ответственность персонала, можно предотвратить злоупотребления со
стороны сотрудников, свести к минимуму роль человеческого фактора в управлении;
· благодаря системе
автоматизации ресторана появляется возможность исключить трудоемкие операции по
учету, обеспечить гибкое управление политикой скидок и бонусов;
· становится возможным
вести непрерывный мониторинг работы всех структур заведения, анализировать и
прогнозировать результаты деятельности ресторана.
Таким образом, в результате автоматизации предприятия
ресторатор имеет возможность постоянно повышать конкурентоспособность,
рентабельность своего бизнеса.
данные программный запрос таблица инфологический
.1 Этапы и основные принципы проектирования баз
данных
Процесс проектирования состоит в переходе от одного уровня
абстракции в представлении данных к другому. Этот процесс представляют
последовательностью более простых, обычно интерактивных, процессов
проектирования менее сложных отображений между промежуточными моделями данных.
Задача системного анализа предметной области (рис. 1) заключается в определении
целей создания системы, изучении предметной области и определении требований
пользователей. Определяются границы предметной области, отбрасываются
несущественные части. Накапливаются знания о предметной области. Описание
обычно делается на естественном языке. Задача инфологического этапа
проектирования - получение семантических (смысловых) моделей, отражающих
информационное содержание предметной области. Главными элементами
концептуальной модели являются объекты и их отношения. На этом этапе
определяются объекты, т. е. те вещи, которые пользователи считают особенно
важными, их свойства и связи между ними.
Таким образом на этом этапе, согласно поставленной задачи, мы
можем выделить объекты из которых будет состоять будущая база данных:
Рисунок 1 - Системный анализ предметной области
Затем составляется инфологическая концептуальная модель в
соответствии с требованиями пользователей. Описывается информация, требуемая
каждому конкретному пользователю, то есть запросы к базе данных. Формируются
описания внешних инфологических моделей, их взаимная увязка с инфологической
концептуальной моделью. Полученные описания отражают составляющие предметной
области, связи между ними. Эти описания не должны зависеть от методов
представления данных и от конкретной СУБД. Концептуальная инфологическая модель
должна обеспечивать прочную и долговременную работу всей системы, выдерживать
замену одной СУБД на другую.
Задача логического этапа проектирования - организация данных,
выделенных на предыдущем этапе, в форму, выбранную в конкретной СУБД.
Инфологическая модель должна быть отображена в компьютеро-ориентированную
даталогическую модель, «понятную» СУБД. В процессе развития теории и практического
использования БД создавались СУБД, поддерживающие различные даталогические
модели. Иными словами, требуется разработать схему концептуальной и внешних
моделей данных, пользуясь только теми типами данных и их особенностями, которые
поддерживаются данной СУБД. На этом этапе обычно не прорабатываются вопросы,
связанные с организацией хранения и доступа к данным на внутреннем уровне, но
методы доступа выбираются. Задача физического этапа проектирования - выбор
рациональной структуры хранения данных и методов доступа к ним, исходя из
арсенала методов и средств, который предоставляется данной СУБД.
Системный анализ предметной области
При проектировании информационной системы необходимо провести
анализ целей этой системы и выявить требования к ней отдельных пользователей. В
рамках системного анализа необходимо провести подробное словесное описание
объектов предметной области и реальных связей, которые между ними существуют.
Таким образом, мы можем выявить уже на этом этапе основные
объекты нашей базы данных, такие как должности, сотрудники, заказ, меню и
склад.
Все объекты баз данных имеют свои атрибуты, например, у
объекта сотрудники будут такие атрибуты как: код сотрудника, должность, ФИО,
адрес, телефон и др., где атрибут код должности является ключевым, по которому
в дальнейшем будет реализована связь.
При проектировании банков данных для определения границ
предметной области используются два подхода: функциональный или «от запросов
пользователей» и предметный или «от реального мира». Функциональный подход применяется
тогда, когда заранее известны функции некоторой группы лиц или комплексов
задач, для обслуживания которой создается БД. В этом случае можно четко
выделить набор объектов предметной области, которые должны быть описаны.
Предметный подход применяется тогда, когда информационные
потребности пользователей БД жестко не фиксируются. Они могут быть
разнообразными и динамичными. В этом случае невозможно выделить минимальный
набор объектов предметной области, которые необходимо описывать и в описание
включаются те объекты и взаимосвязи, которые наиболее существенны для данной
предметной области. Созданная таким образом БД может быть использована при
решении множества разнообразных, заранее не определенных задач. Однако при
таком подходе возможно создание настолько сложной БД, что она окажется
неэффективной для конкретных задач. Чаще всего используется комбинированный
подход, который позволяет учесть конкретные потребности пользователей и в то же
время предусматривает возможность наращивания новых приложений для создаваемой
БД.
Инфологическая модель отображает реальный мир в некоторые
понятные человеку концепции, полностью независимые от параметров среды хранения
данных. Существует множество подходов к построению таких моделей: графовые
модели, семантические сети, модель «сущность-связь» и т. д. Наиболее популярной
из них оказалась модель «сущность-связь». В инфологическом подходе выделяются:
Сущность (Объект) - это то, о чем должна накапливаться информация в системе.
Необходимо различать такие понятия, как тип сущности и экземпляр сущности.
Типом сущности иди объектным множеством.
Конкретизация. Объектное множество, являющееся подмножеством
другого объектного множества.
Обобщение. Объектное множество, являющееся надмножеством
другого объектного множества (содержащее его).
Объекты могут быть атомарными или составными, причем объект
может в одном приложении быть атомарным, а в другом - составным. Для составного
объекта должны быть определены его внутренние составляющие. Каждый объект в
определенный момент времени характеризуется определенным состоянием. Это
состояние описывается с помощью набора свойств и связей с другими объектами.
Свойства объекта могут не зависеть от его связей (отношений) с другими
объектами. Такие свойства называются локальными. Свойства, которые зависят от
связей с другими объектами, называются реляционными. Связь (отношение) между
объектами в зависимости от числа входящих в нее объектов характеризуется
мощностью. Мощность - это максимальное количество элементов одного объектного
множества, связанных с одним элементом другого объектного множества. Некоторые
отношения не имеют конкретного значения максимальной мощности, тогда мощность
обозначают *, т. е. «много».
2.1 Модель «Сущность - Связь» (ERD)
Это модель предметной области, которая используется на этапе
инфологического проектирования. Нотация ERD была впервые введена П. Ченом
(Chen). Модель использует три основных элемента: сущность, атрибут и связь.
Сущность - это абстракция какого-либо объекта, процесса или явления реального
мира, о котором нужно хранить информацию. В качестве сущности могут выступать
материальные и нематериальные объекты. Тип сущности определяет набор однородных
объектов, а экземпляр сущности - конкретный объект в наборе. Каждый тип сущности
обладает одним или несколькими атрибутами. Каждому типу сущности должно быть
дано уникальное имя. К одному и тому же имени должна всегда применяться одна и
та же интерпретация.
Для идентификации конкретных экземпляров сущностей
используются атрибуты - идентификаторы (один или несколько), которые позволяют
однозначно отличать один экземпляр сущности от другого. Каждая сущность может
обладать любым количеством связей с другими сущностями модели. Атрибут - это
поименованная характеристика сущности, которая принимает значения из некоторого
множества значений. Например, для сущности ДОЛЖНОСТИ атрибутами являются
Наименование должности, Код должности, Требования и т. п. Чтобы задать атрибут
в модели, необходимо присвоить ему наименование, привести смысловое описание
атрибута, определить множество его допустимых значений и указать, для чего он
используется. Основное назначение атрибута - описание свойства сущности, а
также идентификация экземпляров сущности. Атрибут можно использовать и как
связь - это тоже признак сущности. Атрибут может быть либо обязательным, либо
необязательным. Обязательность означает, что атрибут не может принимать
неопределенных значений (null values). Атрибут может быть либо описательным (т.
е. обычным дескриптором сущности), либо входить в состав уникального
идентификатора (первичного ключа). Первичный ключ - набор атрибутов, значения
которого однозначно определяют экземпляр сущности. Внешний ключ - это набор
атрибутов, используемый для представления связей между сущностями. Связи - поименованная
ассоциация между двумя сущностями, значимая для рассматриваемой предметной
области. Связь - это средство, с помощью которого представляются отношения
между сущностями, имеющие место в предметной области. Связи может даваться имя,
выражаемое грамматическим оборотом глагола. Имя каждой связи между двумя
данными сущностями должно быть уникальным, но имена связей в модели не обязаны
быть уникальными.
Связи могут быть между двумя (бинарные), тремя (тернарные) и
более сущностями. Чаще всего используются бинарные. Они классифицируются
следующим образом: Связь «один - к - одному» (отображение 1 : 1). Когда каждому
экземпляру сущности А соответствует один и только один экземпляр сущности Б, и
наоборот. Связь двунаправленная. Связь «один - ко - многим» (отображение 1: М).
Это такой тип связи, когда каждому экземпляру сущности А может соответствовать
ни одного, один или несколько экземпляров сущности Б, однако каждому экземпляру
сущности Б соответствует один и только один экземпляр сущности А. Связь «многие
- к - одному» (отображение М: 1). Это отображение обратно предыдущему. Связь
«многие - ко - многим» (отображение М: N). Это такой тип связи, при котором
каждому экземпляру сущности А может соответствовать ни одного, один или
несколько экземпляров сущности Б, и наоборот.
В нашей базе данных используются связи «один - ко - многим» и
«многие - к - одному» (отображение М: 1), например такие как Должности
<=>> Сотрудники, где на одной должности могут находится разные люди
одновременно, Заказ <<=> Меню, где одно из одного и того же меню можно
сделать заказ блюда неоднократно и т.д.
В некоторых случаях целесообразно рассматривать
однонаправленную связь от сущности А к сущности Б. Она может быть простой и
многозначной. При простой однонаправленной связи от А к Б одному и тому же
экземпляру А соответствует один и тот же экземпляр Б. При этом обратная связь
не определена. При многозначной однонаправленной связи от А к Б, одному и тому
же экземпляру А соответствует ни одного, один или несколько экземпляров Б.
Обратная связь не определена. Во многих случаях интересен не сам факт
отношения, а его мощность, выраженная в числовой форме. Она называется
показателем и широко используется в управленческой деятельности. В этих случаях
тип отношения можно рассматривать как тип сущности и он может иметь
описательные атрибуты. Например, «Деталь А размещена на складе Б» рассматриваем
как сущность, о которой хотим хранить информацию о количестве деталей на складе
(атрибут - количество).
Информацию о проекте оформляют составлением спецификаций по
сущностям, атрибутам и отношениям с использованием графических диаграмм. На
диаграмме обозначают:
атрибуты - овалами, соединяя их с соответствующими сущностями
ненаправленными ребрами; идентифицирующие атрибуты подчеркиваются;
связи (отношения) - ромбами, соединяя их с соответствующими
сущностями ненаправленными ребрами, за исключением бинарных связей, которые
соединяются направленными ребрами.
Инфологическая модель БД Ресторана представлена на рис.2.
Рисунок 2 - Инфологическая модель базы данных
2.2 Структурный подход при разработке
инфологической модели
Сущность структурного подхода к разработке ИС заключается в
ее декомпозиции (разбиении) на автоматизируемые функции: система разбивается на
функциональные подсистемы, которые в свою очередь делятся на подфункции,
подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до
конкретных процедур. При этом автоматизируемая система сохраняет целостное
представление, в котором все составляющие компоненты взаимоувязаны. При
разработке системы «снизу - вверх» от отдельных задач ко всей системе
целостность теряется, возникают проблемы при информационной стыковке отдельных
компонентов. При моделировании предметной области проектировщик разбивает ее на
ряд локальных областей, моделирует каждое локальное представление, а затем их
объединяет.
Одни и те же данные могут группироваться в таблицы
(отношения) различными способами, т.е. возможна организация различных наборов
отношений взаимосвязанных информационных объектов. Группировка атрибутов в
отношениях должна быть рациональной, т.е. минимизирующей дублирование данных и
упрощающей процедуры их обработки и обновления.
Определенный набор отношений обладает лучшими свойствами при
включении, модификации, удалении данных, чем все остальные возможные наборы
отношений, если он отвечает требованиям нормализации отношений.
Нормализация отношений - формальный аппарат ограничений на
формирование отношений (таблиц), который позволяет устранить дублирование,
обеспечивает непротиворечивость хранимых в базе данных, уменьшает трудозатраты
на ведение (ввод, корректировку) базы данных.
Выделены три нормальные формы отношений и предложен механизм,
позволяющий любое отношение преобразовать к третьей (самой совершенной)
нормальной форме.
Отношение называется нормализованным или приведенным к первой
нормальной форме, если все его атрибуты простые (далее неделимы). Преобразование
отношения к первой нормальной форме может привести к увеличению количества
реквизитов (полей) отношения и изменению ключа.
Например, отношение Сотрудники = ( Код должности ,
ФИО, № паспорта, Адрес, телефон, возраст, код должности) находится в первой
нормальной форме.
Чтобы рассмотреть вопрос приведения отношений ко второй
нормальной форме, необходимо дать пояснения к таким понятиям, как
функциональная зависимость и полная функциональная зависимость.
Описательные реквизиты информационного объекта логически
связаны с общим для них ключом, эта связь носит характер функциональной
зависимости реквизитов.
Функциональная зависимость реквизитов - зависимость, при
которой экземпляре информационного объекта определенному значению ключевого
реквизита соответствует только одно значение описательного реквизита, к
примеру, в таблице заказы это код сотрудника выполняющего заказ или таблица
склад в которой значению ключевого реквизита соответствует только одно значение
описательного реквизита как код блюда.
Такое определение функциональной зависимости позволяет при
анализе всех взаимосвязей реквизитов предметной области выделить
самостоятельные информационные объекты.
Понятие третьей нормальной формы основывается на понятии
нетранзитивной зависимости. Транзитивная зависимость наблюдается в том случае,
если один из двух описательных реквизитов зависит от ключа, а другой
описательный реквизит зависит от первого описательного реквизита.
Отношение будет находиться в третьей нормальной форме, если
оно находится во второй нормальной форме, и каждый неключевой атрибут
нетранзитивно зависит от первичного ключа.
Для устранения транзитивной зависимости описательных
реквизитов необходимо провести «расщепление» исходного информационного объекта.
В результате расщепления часть реквизитов удаляется из исходного
информационного объекта и включается в состав других (возможно, вновь
созданных) информационных объектов. На (рис. 3) представлено схематическое
представление нормальных форм БД.
Рисунок 3 - Схема процесса нормализации
.1 Классификация и сравнительная характеристика
СУБД
Классифицировать СУБД можно по следующим признакам:
по используемой модели данных (классификация МД будет
рассмотрена далее);
по способу организации БД (централизованная или
распределенная);
по реализуемым режимам работы (однопользовательский,
многопользовательский и т. д.);
по способам физической организации данных.
Наиболее существенным критерием для сравнения СУБД являются
эксплуатационные характеристики, такие как надежность, высокая готовность,
производительность, масштабируемость. Сравнительный анализ основных СУБД по
этим показателям производится на основе экспертных оценок. Пример такого анализа
приведен в табл. 1.
Таблица 1 - Сравнительный анализ СУБД Microsoft SQL Server и
Oracle
Функция
соединения и выбор индексов
Одновременный
доступ нескольких пользователей
Обработка
аудио, видео, изображений
Работа под
управлением различных ОС
Курсовая работа по разработке информационной системы для ресторана
Проектирование базы данных ' Ресторан '. Дипломная (ВКР). Информационное...
Проект базы данных ресторана | Содержание работы
Создание базы данных " Ресторан " (на примере ресторана "Волна")
Реферат: База данных Меню ресторана - BestReferat.ru
курсовая работа - Разработка базы данных и приложения для решения задачи...
Курсовая Работа База Данных Ресторан Бесплатно Рефераты
Курсовая работа : Курсовая : Разработка базы данных для... - Studrb.ru
Создание базы данных Ресторан в Access 2013 - YouTube
База данных Access Ресторан - Базы данных Access
Курсовая работа " База данных "Кафе" (формирование счета в кафе)" на...
Проектирование базы данных " Ресторан " | Похожие работы
Курсовая работа (Теория) на тему "Разработка базы данных ..."
Курсовая : "Разработка базы данных информационной системы « Ресторан »..."
Введение
Московские Диссертации
Этические Нормы Информационной Деятельности Реферат
Можно Ли Доверять Роботам Эссе
Аргументация Эссе По Обществознанию
Защита Окружающей Среды Сочинение На Немецком