разработка базы данных для ресторана фастыуда. Курсовая работа по дисциплине Разработка базы данных для автоматизации учёта продаж и аренды товаров в свадебном салоне
 Скачать 1.61 Mb.
|
2 ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ2.1 Семантическая модель данныхЧтобы перейти к созданию семантической модели необходимо проанализировать предметную область, изучить ее информационную структуру. Пусть на модели сущности обозначаются прямоугольниками, связываются с другими сущностями линиями, а сложные связи обозначаются ромбами. Указывается тип связи 1:1, или 1:* (один ко многим), *:* (многие ко многим). [7] Разработку модели начнем с выделения основных сущностей и связей между ними. Выделим сущность «Сотрудники». Каждый сотрудник имеет уникальный табельный номер, который является его первичным ключом, и другие атрибуты, которые взяты из описания предметной области. Сотрудники обслуживают клиентов. Выделим сущность «Клиенты», который имеет свой уникальный «ID-клиента», являющийся его первичным ключом, и ряд атрибутов, которые взяты из описания предметной области. Клиенты могут приобрести либо взять в аренду свадебные платья и купить аксессуары к ним: перчатки либо фату. Выделим следующие сущности реализуемых товаров в свадебном салоне: «Платья», «Перчатки», «Фата». Каждая сущность товаров должна иметь свой первичный ключ. Для сущности «Платья» – это код платья, для «Перчатки» - код перчаток и «Фата» - код фаты. Атрибуты данных сущностей взяты из описания предметной области. Связав сущности «Сотрудник», «Клиент» и «Платья», «Перчатки», «Фата» получим ситуацию, в которой клиент, консультируемый сотрудником, покупает либо арендует товары из предложенного ассортимента свадебного салона. Возникает необходимость создать сложные связи. Для обозначения сложных связей применим ромбы, назовём связи «Договор аренды» и «Продажа». Рассмотрим сложную связь «Договор Аренды». Атрибуты могут присваиваться связям, поэтому, так как необходимо зафиксировать дату взятия в аренду и дату возврата и итоговую стоимость, связь «Договор аренды» будет описываться следующими атрибутами: «ДатаЗаключенияДоговора», «ДатаОкончанияДоговора», «ПаспортныеДанныеАрендатора», «ИтоговаяСтоимостьАренды», которые взяты из описания предметной области. Так как свадебный салон занимается прокатом платьев, то для осуществления аренды в ней должны участвовать клиент, сотрудник и платья, поэтому со стороны сущностей «Клиент», «Сотрудник» связь является обязательной. Так как все платья могут быть взяты в аренду, то со стороны сущности «Платья» связь является обязательной. Так как при заключении каждого договора аренды в нем участвуют один клиент и один сотрудник, то кратность сущностей «Клиент» и «Сотрудник» равны «один». Так как в каждой аренде могут участвовать несколько платьев, то кратность сущностей «Платья» равны «многие». Рассмотрим вторую сложную связь «Продажа». Как и в случае сложной связи «Договор аренды», данной связи «Продажа» могут присваиваться атрибуты, поэтому, так как необходимо зафиксировать дату продажи и итоговую стоимость продажи, связь «Продажа» будет описываться следующими атрибутами: «ДатаПродажи», «Количество товаров» и «ИтоговаяСтоимостьПродажи», которые взяты из описания предметной области. Так как для осуществления продажи в ней должны участвовать клиент, сотрудник и платья либо аксессуары к ним, поэтому со стороны сущностей «Клиент», «Сотрудник», «Перчатки», «Фата» и «Платья» связь является обязательной. Так как при заключении каждой продажи в ней участвуют один клиент и один сотрудник, то кратность сущностей «Клиент» и «Сотрудник» равны «один». Так как в каждой продаже могут участвовать несколько платьев и несколько аксессуаров, то кратность сущностей «Платья» и «Перчатки», «Фата» равны «многие». Семантическая модель предметной области представлена в приложении А. 2.2 Логическая модель данныхПреобразуем семантическую модель данных в логическую в соответствии с правилами формирования отношений. На месте сложной связи создадим новое отношение «Договор аренды». Пусть созданная сущность, который имеет свой уникальный номер договора, являющийся его первичным ключом, и ряд атрибутов, которые взяты из описания предметной области. Между сущностями «Платья» и «Договор аренды» существуют связи (*:*), обязательные с двух сторон. Это свидетельствует о том, что будут созданы новые отношения. Назовём такое отношение соответственно «Аренда платьев». Сущности «Платья» и «Договор аренды» передают копию своего первичного ключа «КодПлатья» и «НомерДоговора» в новую сущность «Аренда платьев» для создания сложного первичного ключа. Между сущностями «Платья» и «Продажа», «Перчатки» и «Продажа», «Фата» и «Продажа» существуют связи (*:*), обязательные с двух сторон. Это свидетельствует о том, что будут созданы новые отношения. Назовём такие отношения − «Продажа платьев», «Продажа перчаток» и «Продажа фаты» соответственно. Сущности «Платья» и «Продажа», «Перчатки» и «Продажа», «Фата» и «Продажа» передают копию своего первичного ключа «КодПлатья», «КодПерчаток» и «КодФаты» соответственно тем самым формируя в новые сущности сложные первичные ключи. Выполним проверку полученных отношений на соответствие нормальным формам. Отношение находится в первой нормальной форме тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов.[11] Отношения базы данных соответствуют первой нормальной форме, поскольку на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. На соответствие второй нормальной форме проверяются только отношения, имеющие составной первичный ключ. Отношение находится во второй нормальной форме тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей не ключевых атрибутов от атрибутов составного первичного ключа. Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей, то есть зависимостей неключевых атрибутов от неключевых. Отношение базы данных соответствуют третьей нормальной форме, поскольку не содержат транзитивных зависимостей, то есть зависимостей не ключевых атрибутов от не ключевых. Отношение находится в нормальной форме Бойса–Кодда, если оно находится в третьей нормальной форме, и каждый детерминант отношения является возможным ключом отношения, то есть отношение не должно содержать зависимостей ключевых атрибутов от неключевых. Отношения базы данных соответствуют нормальной форме Бойса-Кодда, поскольку каждый детерминант отношения является возможным ключом отношения.[12] На соответствие четвертой нормальной форме проверяются отношения, имеющие многозначные атрибуты. Отношение находится в четвертой нормальной форме, если оно находится в третьей нормальной форме, и в нем отсутствуют многозначные зависимости не ключевых атрибутов от ключевых. Отношения базы данных соответствуют четвертой нормальной форме, поскольку в них отсутствуют многозначные зависимости не ключевых атрибутов от ключевых.[10] Логическая модель предметной области представлена в приложении Б. |