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

 

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Нормализация - это процесс приведения структуры реляционных отношений к форме, обладающей лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т. е. исключена избыточность информации. Кроме задачи более эффективного использования памяти, нормализация позволяет снизить угрозу нарушения целостности базы данных из-за появления в ней внутренних противоречий [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НФ и ни один из его неключевых атрибутов не зависит функционально от любого другого неключевого атрибута.

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

 [1 – c. 66].

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

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

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

 

 

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

 

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

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

 

Список заведений
Код зав-ния	Название	Контакты	Описание
1	Кофейня "Эгоист"	пр-т Н. Абдирова, 25, тел: +7 (7212) 793-596	Режим работы: 12.00-2.00. Кухня: европейская, японская, десертная карта. Мест: 30-35
2	Ресторан "Шинок"	пр-т Н. Абдирова, 25, тел: +7 (7212) 510-600	Режим работы: 12.00-2.00. Кухня: русская, украинская. Мест: 55
3	Ресторан "Chilli Pepper"	пр-т Н. Абдирова, 25, тел: 8 (7212) 510-600	Режим работы: 10.00-2.00. Кухня: европейская, мясная. Мест: 30
4	Кофейня "Шарлотка"	ТРЦ "City Mall", 2 этаж	Режим работы: 10.00-22.00. Кухня: европейская, десертная карта. Мест: 80
5	Ресторан "Vertuoz Asia Mix Cafe"	ул. Ермекова, 52, тел: +7 (7212) 477-621, +7 (702) 288-70-26 (директор Цыпалюк Ю.В.)	Режим работы: 12.00-2.00. Кухня: японская, китайская, корейская. Мест: 35-40
6	Кафе "Basilico"	ул. Ермекова, 52, тел: +7 (7212) 477-621, +7 (702) 288-70-26 (директор Калышева Л.Б.)	Режим работы: 12.00-2.00. Кухня: итальянская. Мест: 25-30

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

 

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

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

• целостность отношений;
• ссылочная целостность.

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

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

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

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

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

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

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

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

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

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

 

 

 

 

 

 

 

 

 

 

2. СУБД.

 

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

 

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

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

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

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

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

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