Разработка базы данных для информационных систем салона красоты "Афродита"

Размещено на http://www.allbest.ru/

Государственное образовательное учреждение высшего профессионального образования Московский Технический Университет Связи и Информатики

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

Кафедра Математической Кибернетики и Информационных Технологий

Курсовой проект по дисциплине "Базы данных"

Разработка базы данных для ИС салона красоты "Афродита"

Выполнил: Пономарев Алексей Сергеевич

Научный руководитель: Воронова Л.И.

Москва 2013 г.

Оглавление

Глава 1. Системный анализ предметной области

1.1 Анализ объекта автоматизации

1.2 Обзор информационных технологий, по направлению разработки СУБД

1.3 Обзор продуктов-аналогов

1.4 Требования к разрабатываемой базе данных

Глава 2. Проектирование БД для ООО "Афродита"

2.1 Разработка инфологической модели предметной области

2.2 Выбор модели данных

2.3 Алгоритм преобразования инфологической модели в реляционную

2.4 Даталогическое проектирование

Глава 3. Программная реализация БД

3.1 Разработка отчетов

Заключение

Список источников и литературы

Введение

Информационная система (ИС) - это совокупность технических, организационных, информационных и программных средств, которые объединены в единую систему с целью сбора, хранения, обработки и выдачи информации. Информационная система предназначена для выполнения заданных функций. В рамках современного понимания информационной системы компьютер является основным инструментом обработки информации. Ядро операционной системы - база данных.[1]

База данных (БД) [database (DB)] - совокупность описаний реальных объектов, определенным образом структурированных и связанных между собой, актуальных для конкретной предметной области и представленных на электронных носителях.[2]

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

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

Глава 1. Системный анализ предметной области

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

1.1 Анализ объекта автоматизации

Салон красоты "Афродита" ведёт своё существование с 1 декабря 2012 года. Первоначально, он представлял из себя небольшую парикмахерскую. С течением времени он переезжал из одного помещения в другое, расширяя возможности и закупая новое оборудование.

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

Рассмотрим основные объекты предметной области.

В базу данных будет заноситься следующая информация о клиентах:

- Фамилия Имя Отчество (ФИО)

- Дата рождения

- Пол

- Телефон

- Email

- Дата регистрации

Для каждого клиента, если он хочет получить какую-либо услугу, заводится запись "визит":

- Порядковый номер

- ФИО клиента

- Услуга

- ФИО сотрудника

- Дата

Для каждого визита хранится его статус. Статус может быть "Услуга оказана", "Ожидается", "Клиент не пришел":

- Порядковый номер визита

- Статус

Так же в базе данных хранится информация о сотрудниках салона красоты. Каждому сотруднику соответствует уникальный код.

- Код сотрудника

- Фамилия Имя Отчество (ФИО)

- Должность

- Логин

- Телефон

- Адрес

- Дата приема на работу

Предусмотрена регистрация пользователей:

- Логин

- Пароль

В специализацию салона красоты входит несколько направлений: косметология, массаж, парикмахерская, маникюр, стиль, визаж. Каждый мастер салона красоты имеет свою специализацию.

- Должность

- Оклад

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

- Название услуги

- Затрачиваемое время

- Используемый материал

- Количество материала

- Цена

Ограничения для предметной области будут следующие:

1) Минимальный оклад должен быть не менее 10000 рублей, в соответствии с МРОТ для Московской области на 2013 год;

2) Дата приема на работу не может быть менее 01.12.2012, т.к. до этой даты салон ещё не работал.

3) Дата регистрации клиента не может быть менее 01.12.2012, т.к. до этой даты салон ещё не работал.

4) у каждого клиента должны быть обязательно заполнены все данные, кроме дня рождения;

5) у каждой услуги должны обязательно быть заполнены все данные;

1.2 Обзор информационных технологий, по направлению разработки СУБД

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

СУБД можно условно разделить на следующие классы:

· домашние (настольные) СУБД - подходят для использования в домашних условиях и создания небольших баз данных;

· полупрофессиональные СУБД - в основном используются предприятиями малого бизнеса для проектирования баз данных обычных размеров;

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

Домашние (настольные) СУБД

Microsoft Access

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

В отличие от других настольных СУБД, Access хранит все данные в одном файле, хотя и распределяет их по разным таблицам, как и положено реляционной СУБД. К этим данным относится не только информация в таблицах, но и другие объекты базы данных, которые будут описаны ниже.[5]

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

Полупрофессиональные СУБД

MySQL

MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

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

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

MySQL портирована на большое количество платформ:AIX, BSDi, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista и Windows 7. Существует также порт MySQL на OpenVMS. Важно отметить, что компания MySQL AB предоставляет для свободной загрузки не только исходные коды СУБД, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули.

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы.NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.[6]

Профессиональные СУБД

Microsoft SQL Server

Cистема управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов - Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для небольших и средних по размеру баз данных, и в последние 5 лет - для крупных баз данных масштаба предприятия, конкурирует с другими СУБД в этом сегменте рынка.

Функциональность.

Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.

Microsoft SQL Server также поддерживает Open Database Connectivity (ODBC) - интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.[7]

Oracle Database XE

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

Новая редакция СУБД Oracle Database 10g предоставляет возможность разработчикам ПО, администраторам баз данных и всем, кто впервые использует технологии Oracle, получить бесплатную базовую версию СУБД, позволяющую начать разработку и развертывание собственных приложений. Кроме того, эта версия предлагается бесплатно независимым разработчикам программного обеспечения и поставщикам оборудования для свободной дистрибуции или встраивания в собственные приложения.

"Oracle Database XE предоставляет разработчикам, администраторам БД, независимым поставщикам ПО и студентам возможность бесплатно изучать, а также создавать и развертывать собственные разработки на базе самой передовой СУБД, - говорит Томас Кайт (Thomas Kyte), вице-президент Oracle. - Никто еще не предлагал подобного - теперь каждый имеет возможность начать свою работу с самым лучшим решением на рынке".

"Разработчики, администраторы БД, студенты и независимые поставщики ПО часто ищут бесплатные СУБД для изучения основ и разработки приложений, взаимодействующих с базами данных, - рассказывает Карл Олофсон (Carl Olofson), директор по исследованиям в области управления информацией и ПО для интеграции данных аналитической компании IDC. Если такая СУБД сопровождается достаточным количеством необходимой литературы, онлайновыми техническими материалами и профессиональной поддержкой экспертов, если она позволяет разработчикам развивать свои приложения и поддерживать их по мере расширения требований без необходимости конвертации баз данных, то эта платформа обеспечит надежный путь развития с высоким потенциалом не только в ближайшем будущем, но и в отдаленной перспективе".

Редакция Oracle Database XE предоставляет те же интерфейсы SQL и PL/SQL, что и во всех остальных версиях Oracle Database 10g, а также широкий спектр программных интерфейсов, удовлетворяющих потребности различных сообществ разработчиков. Например, предоставляется полная поддержка разработки и развертывания приложений для разработчиков, работающих на платформах Java,.NET, PHP и Windows. Кроме того, Oracle Database XE предоставляет разработчикам возможность воспользоваться преимуществами Oracle HTML DB для быстрой разработки и развертывания Web-приложений.[8]

Редакция Oracle Database XE выпускается для 32-разрядных операционных систем Linux и Windows и может быть установлена на любой поддерживаемой ими аппаратной платформе.

Являясь бесплатной, базовой версией БД Oracle Database XE имеет некоторые ограничения:

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

· использование памяти ограничено 1 ГБ;

· использование СУБД ограничено одним экземпляром СУБД в каждой вычислительной системе; и,

· объем пользовательских данных в БД ограничен 4 ГБ.

Независимые поставщики ПО имеют право распространять и/или встраивать Oracle Database XE в свои продукты при условии выполнения перечисленных выше ограничений использования.

В качестве платформы для физической реализации разработанной БД была выбрана СУБД Oracle Database 11g XE, а для удобства разработки и администрирования Oracle SQL developer.

1.3 Обзор продуктов-аналогов

В настоящее время на рынке информационных систем позиционируются продукты, имеющие аналогичные с разрабатываемой ИС объекты автоматизации, например, АСУ "SPA Insight" и АСУ "UNIVERSE-Красота ". Рассмотрим подробнее данные продукты и приведем их основные особенности.

АСУ "SPA Insight"

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

Зачем нужна программа Spa Insight?

Spa- Insight помогает решить следующие задачи:

§ Повышение качества обслуживания клиентов

§ Внедрение "сервисного" отношения к клиентам

§ Ведение истории обслуживания и предпочтений клиентов

§ Контроль управленческих расходов и снижение материальных издержек

§ Контроль остатков товаров в реальном режиме времени

§ Контроль работы персонала

§ Оценка корректности норм списания материальных ценностей

§ Оценка эффективности использования персонала и оборудования

§ Анализ загрузки персонала и оборудования

§ Учет текущего состояния оборудования

§ Прогнозирование работы предприятия на основании статистических данных

§ Выручки, прибыли, себестоимости продукции

§ Вклада сотрудников в работу предприятия

§ Оценка рентабельности и сезонности спроса на услуги

§ Рекомендации по объемам закупки товаров на склад

Преимущества Spa Insight

Spa Insight позволяет интегрировать в единый комплекс решение двух основных задач автоматизации работы предприятия индустрии красоты и здоровья:

§ Регистрация продаж (зал): рабочее место менеджера /администратора/ мастера + касса;

§ Управление складом (офис): рабочее место товароведа/бухгалтера.

Технические преимущества системы Spa Insight

§ Тщательно продуманный интуитивно понятный пользовательский интерфейс, который максимально упрощает процесс обучения персонала;

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

§ Возможность интеграции с автоматизированными системами смежных отраслей (гостиниц, ресторанов, развлекательных центров и т.д.);

§ Многопользовательский режим работы системы с четко разграниченными правами доступа к данным;

§ Гибкий механизм резервного копирования данных, повышающий надежность и отказоустойчивость системы;

§ Механизм on-line обновления программных модулей системы (при условии наличия подключения к Интернет);

§ Современный легко настраиваемый дизайн.

АСУ "UNIVERSE-Красота"

По мнению многочисленных клиентов, достаточно нескольких дней работы с системой "UNIVERSE-Красота", чтобы вы смогли на практике оценить следующие приоритеты предлагаемой программы:

-простота и удобство управления всеми опциями;

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

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

-возможность ведения системы пластиковых карт для клиентов;

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

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

Программное обеспечение "Юниверс-Красота" является полностью автономным, не требующим приобретения дополнительных базовых пакетов, что позволяет говорить о полной маркетинговой независимости покупателя.

Интегрированная в SPA-центр или салон красоты программа "UNIVERSE-Красота" предоставит возможность формировать отчёты и осуществлять контроль в автоматическом режиме над следующими позициями:

-реализация основных и сопутствующих товаров;

-закупка и расход косметических и других препаратов;

-оплата клиентами профильных услуг;

-общая посещаемость салона;

-начисление заработной платы;

-складская инвентаризация;

-расходы на рекламное продвижение, включая финансовую эффективность проводимых акций

1.4 Требования к разрабатываемой базе данных

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

С данной базой данных могут работать следующие группы пользователей:

§ системный администратор - управляющий, имеющий неограниченный доступ к БД;

§ директор - руководящая должность в салоне красоты;

§ менеджер - администратор салона красоты;

§ мастер - сотрудник салона красоты;

§ клиент - клиент салона красоты;

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

§ вносить изменения в личные данные сотрудников;

§ добавлять новых сотрудников;

§ вносить изменения в информацию о должностях;

§ добавлять новые должности;

§ просматривать любую информацию;

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

§ вносить изменения в информацию о клиентах, визитах, услугах и статусах;

§ добавлять информацию о клиентах, визитах, услугах и статусах;

§ просматривать информацию о клиентах, сотрудниках, визитах, услугах и статусах;

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

§ просматривать информацию о визитах;

§ просматривать информацию об услугах;

При работе с базой данных клиент может:

§ просматривать информацию об услугах;

Выводы.

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

В ходе обзора информационных технологий перечислены классы СУБД, приведены примеры для каждого класса и определены достоинства и недостатки следующих СУБД: Microsoft Access, MySQL, Microsoft SQL Server, Oracle Database XE.

Рассмотрены продукты-аналоги на рынке информационных систем (АСУ "Spa Insight ", АСУ "UNIVERSE-Красота") и даны описания данных систем.

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

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

Глава 2. Проектирование БД для ООО "Афродита"

Глава содержит практическую часть, связанную с моделированием предметной области и базы данных. В ней описывается разработка инфологической модели (ER-модели). Затем производится выбор даталогической модели данных. Далее описывается алгоритм преобразования инфологической модели в даталогическую. Проводится нормализация схемы БД. Здесь же производится описание проектирования интерфейса и необходимых приложений. В конце главы формулируются выводы.

2.1 Разработка инфологической модели предметной области

Вторым этапом разработки ИС является инфологическое моделирование. Инфологическая модель представляет собой формализованное описание предметной области. Она создается для того, чтобы заказчик мог ознакомиться со структурой и основными концепциями проектируемой ИС, а разработчик продолжил разработку на основе этой модели. Именно поэтому модель должна быть понятной и легко воспринимаемой как для специалистов по БД, так и для специалистов в предметной области.

В качестве графической нотации в данной работе использовалась "Crow's foot". автоматизация информационный технология клиентский

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

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

Атрибуты сущности записываются внутри прямоугольника, изображающего сущность, и выражаются существительным в единственном числе (возможно, с уточняющими словами). Среди атрибутов выделяется ключ сущности - неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности.[9]

Для информационной системы салона красоты "Афродита" на основе проведенного системного анализа предметной области выделены следующие сущности:

· Сотрудники - сущность содержит служебные и персональные данные сотрудников;

· Клиенты - сущность содержит информацию о персональных данных клиентов;

· Визиты - сущность содержит информацию обо всех записях на услуги;

· Пользователи - сущность содержит данные для авторизации в системе;

· Услуги - сущность содержит информацию обо всех услугах;

· Должности - сущность содержит названия должностей и оклады;

· Статус - сущность содержит информацию о статусах визитов.

Также, в модели есть следующие связи:

· Сотрудники занимают должность;

· У сотрудников есть логин и пароль для входа в систему;

· Сотрудники назначаются на оказание услуг;

· Услуги оказываются клиентам;

· Клиенты записываются на оказание услуг;

· У визитов есть статус.

Таким образом, модель принимает следующий вид:

Рис.1 Инфологическая модель БД Салона красоты "Афродита"

2.2 Выбор модели данных

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

Под даталогической понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации. При этом даталогическая модель разрабатывается с учётом конкретной реализации СУБД, также с учётом специфики конкретной предметной области на основе ее инфологической модели[10].

Существует несколько моделей данных:

· Иерархическая модель;

· Сетевая модель;

· Реляционная модель;

· Объектно-ориентированная модель.

Иерархическая модель данных

Иерархическая модель данных - логическая модель данных в виде древовидной структуры.

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

Узел - информационная модель элемента, находящегося на данном уровне иерархии.

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

Сетевая модель данных

Сетевая модель данных - логическая модель данных, являющаяся расширением иерархического подхода.

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

Сетевая БД состоит из набора экземпляров определенного типа записи и набора экземпляров определенного типа связей между этими записями.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

· каждый экземпляр типа записи P является предком только в одном экземпляре типа связи L;

· каждый экземпляр типа записи C является потомком не более чем в одном экземпляре типа связи L.

Реляционная модель данных

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

· Структурный аспект (составляющая) - данные в базе данных представляют собой набор отношений.

· Аспект (составляющая) целостности - отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

· Аспект (составляющая) обработки (манипулирования) - РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

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

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

Термин "реляционный" означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину "отношение" часто встречается слово таблица. Необходимо помнить, что "таблица" есть понятие нестрогое и неформальное и часто означает не "отношение" как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина "таблица" вместо термина "отношение" нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с "плоскими", или "двумерными" таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни "плоскими", ни "неплоскими".[12]

Для лучшего понимания РМД следует отметить три важных обстоятельства:

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

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

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

Принципы реляционной модели были сформулированы в 1969--1970 годах Э.Ф. Коддом (E. F. Codd). Идеи Кодда были впервые подробно изложены в статье "A Relational Model of Data for Large Shared Data Banks", ставшей классической. Строгое изложение теории реляционных баз данных (реляционной модели данных) в современном понимании можно найти в книге К. Дж. Дейта. "C. J. Date. An Introduction to Database Systems" ("Дейт, К. Дж. Введение в системы баз данных").

Объектно-ориентированная база данных

Ещё один подход к построению БД - использование объектно-ориентированных моделей данных (ООМД). Моделирование данных в ООМД базируется на понятии объекта. Для ООМД, не существует общепризнанной модели данных.

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

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

Среди недостатков ООМД следует отметить отсутствие универсальной модели, недостаток опыта создания и эксплуатации ООБД, сложность использования и недостаточность средств защиты данных[13].

Для дальнейшей разработки базы данных выбрана реляционная модель.

2.3 Алгоритм преобразования инфологической модели в реляционную

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

Рассмотрим правила преобразования ER-модели в реляционную.

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

2. Каждый атрибут сущности становится атрибутом соответствующего отношения. Переименование атрибутов должно происходить в соответствии с теми же правилами, что и переименование отношений в п.1. Для каждого атрибута задается конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).

3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).

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

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

2.4 Даталогическое проектирование

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

Для начала, необходимо убрать связи M:N между отношениями "WORKER" и "POST". Создана связующая таблица "WORK_POST", которая содержит следующие поля:

· WORK_POST

Ш workID number NOT NULL (внешний ключ к отношению WORKER)

Ш postID number NOT NULL (внешний ключ к отношению POST)

В этом отношении составной первичный ключ, в который входят оба поля.

Остальные отношения:

· WORKER

Ш workID number NOT NULL PRIMARY KEY

Ш name varchar(50) NOT NULL

Ш phone varchar(25) NOT NULL

Ш address varchar(50) NOT NULL

Ш worksince date NOT NULL

· CLIENT

Ш ClientID number NOT NULL PRIMARY KEY

Ш name varchar(50) NOT NULL

Ш Birth_Date date NULL

Ш sex varchar(25) NOT NULL

Ш phone varchar(25) NOT NULL

Ш email varchar(25) NOT NULL

Ш clientsince date NOT NULL

· USERS

Ш workID number NOT NULL PRIMARY KEY (внешний ключ к отношению VISIT)

Ш login varchar(20) NOT NULL

Ш pswrd varchar(20) NOT NULL

· VISIT

Ш visitID number NOT NULL PRIMARY KEY

Ш clientID number NOT NULL (внешний ключ к отношению CLIENT)

Ш serviceID number NOT NULL (внешний ключ к отношению SERVICE)

Ш workID number NOT NULL (внешний ключ к отношению WORKER)

Ш date date NOT NULL

· STATUS

Ш visitID number NOT NULL PRIMARY KEY (внешний ключ к отношению VISIT)

Ш status varchar(50) NOT NULL

· POST

Ш postID number NOT NULL PRIMARY KEY

Ш title varchar(50) NOT NULL

Ш money number NOT NULL

· SERVICE

Ш serviceID number NOT NULL PRIMARY KEY

Ш title varchar(50) NOT NULL

Ш time varchar(50) NOT NULL

Ш material varchar(50) NOT NULL

Ш count varchar(50) NOT NULL

Ш price number NOT NULL

На основе этих данных построим следующую даталогическую модель:

Рис.2 Даталогическая модель БД Салона красоты "Афродита".

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

В теории РБД выделяется 6 нормальных форм:

· 1НФ(1NF) - первая нормальная форма

· 2НФ(2NF) - вторая нормальная форма

· 3НФ(3NF) - третья нормальная форма

· БКНФ(BCNF) - нормальная форма Бойса - Кодда

· 4НФ(4NF) - четвертая нормальная форма

· 5НФ(5NF) - пятая нормальная форма

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

Обычно бывает достаточно нормализовать отношение до 3НФ. НФ высших порядков учитывают многозадачные зависимости между атрибутами.

Первая нормальная форма (1NF). Отношение находится в 1NF тогда и только тогда, когда на пересечении каждого столбца и каждой строки находится элементарное значение атрибутов.[14] Все отношения в разрабатываемой базе данных уже находятся в 1NF.

Вторая нормальная форма (2NF). Отношение находится в 2NF тогда и только тогда, когда оно: находится в 1NF; отношение не содержит неполных функциональных зависимостей неключевых атрибутов от атрибутов первичного ключа.[14]

Неполной называется такая зависимость A от B, при которой B зависит лишь от части атрибутов A. Для того чтобы в отношении существовали неполные зависимости, в нем должны быть составные ключи и неключевые атрибуты.[14] В рассматриваемой базе данных составной ключ присутствует в отношении WORK_POST. В отношении WORK_POST нет неключевых атрибутов, значит это отношение находится во второй нормальной форме.

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

Третья нормальная форма (3NF). Отношение находится в 3NF тогда и только тогда, когда оно: находится в 2NF; отношение не содержит транзитивных зависимостей.

Функциональная зависимость R.A > R.B называется транзитивной, если существует набор атрибутов, такой что С не является подмножеством A, C не включает в себя B, существует зависимость R.A > R.С, не существует зависимости R.C > R.A и существует зависимость R.С > R.B[14].

Ни одно отношение модели не имеет транзитивных зависимостей, следовательно все они находятся в 3НФ.

Рис.3 Даталогическая модель БД Салона красоты "Афродита"

Выводы.

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

Глава 3. Программная реализация БД

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

Реализация объектов СУБД

Для того, чтобы реализовать объекты СУБД, необходимо описать их на структурированном языке запросов (SQL), используя интерфейс командной строки.

Реализация таблиц

Рассмотрим таблицы, созданные в процессе реализации объектов СУБД:

CREATE TABLE "SALON"."POST"

("POSTID" NUMBER NOT NULL ENABLE,

"TITLE" VARCHAR2 (50 BYTE) NOT NULL ENABLE,

"MONEY" NUMBER NOT NULL ENABLE,

CONSTRAINT "POST_PK" PRIMARY KEY ("POSTID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS"

CREATE TABLE "SALON"."CLIENT"

("CLIENTID" NUMBER NOT NULL ENABLE,

"NAME" VARCHAR2 (50 BYTE) NOT NULL ENABLE,

"BIRTH_DATE" DATE,

"SEX" VARCHAR2 (25 BYTE) NOT NULL ENABLE,

"PHONE" VARCHAR2 (25 BYTE) NOT NULL ENABLE,

"EMAIL" VARCHAR2 (25 BYTE) NOT NULL ENABLE,

"CLIENTSINCE" DATE NOT NULL ENABLE,

PRIMARY KEY ("CLIENTID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS"

CREATE TABLE "SALON"."SERVICE"

("SERVICEID" NUMBER NOT NULL ENABLE,

"TITLE" VARCHAR2 (50 BYTE) NOT NULL ENABLE,

"TIME" VARCHAR2 (50 BYTE) NOT NULL ENABLE,

"MATERIAL" VARCHAR2 (50 BYTE) NOT NULL ENABLE,

"COUNT" VARCHAR2 (20 BYTE) NOT NULL ENABLE,

"PRICE" NUMBER NOT NULL ENABLE,

CONSTRAINT "SERVICE_PK" PRIMARY KEY ("SERVICEID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS"

CREATE TABLE "SALON"."STATUS"

("VISITID" NUMBER NOT NULL ENABLE,

"STATUS" VARCHAR2 (50 BYTE) NOT NULL ENABLE,

CONSTRAINT "STATUS_PK" PRIMARY KEY ("VISITID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE,

CONSTRAINT "STATUS_VISIT_FK1" FOREIGN KEY ("VISITID")

REFERENCES "SALON". "VISIT" ("VISITID") ENABLE) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ;

CREATE TABLE "SALON"."USERS"

("WORKID" NUMBER NOT NULL ENABLE,

"LOGIN" VARCHAR2 (20 BYTE) NOT NULL ENABLE,

"PSWRD" VARCHAR2 (20 BYTE) NOT NULL ENABLE,

CONSTRAINT "USERS_PK" PRIMARY KEY ("WORKID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE,

CONSTRAINT "USERS_WORKER_FK1" FOREIGN KEY ("WORKID")

REFERENCES "SALON". "WORKER" ("WORKID") ENABLE) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ;

CREATE TABLE "SALON"."VISIT"

("VISITID" NUMBER NOT NULL ENABLE,

"CLIENTID" NUMBER NOT NULL ENABLE,

"SERVICEID" NUMBER NOT NULL ENABLE,

"WORKID" NUMBER NOT NULL ENABLE,

"DATE" DATE NOT NULL ENABLE,

CONSTRAINT "VISIT_PK" PRIMARY KEY ("VISITID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE,

CONSTRAINT "VISIT_CLIENT_FK1" FOREIGN KEY ("CLIENTID")

REFERENCES "SALON". "CLIENT" ("CLIENTID") ENABLE,

CONSTRAINT "VISIT_SERVICE_FK1" FOREIGN KEY ("SERVICEID")

REFERENCES "SALON"."SERVICE" ("SERVICEID") ENABLE,

CONSTRAINT "VISIT_WORKER_FK1" FOREIGN KEY ("WORKID")

REFERENCES "SALON"."WORKER" ("WORKID") ENABLE) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ;

CREATE TABLE "SALON"."WORK_POST"

("WORKID" NUMBER NOT NULL ENABLE,

"POSTID" NUMBER NOT NULL ENABLE,

CONSTRAINT "WORK_POST_PK" PRIMARY KEY ("WORKID", "POSTID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE,

CONSTRAINT "WORK_POST_WORKER_FK1" FOREIGN KEY ("WORKID")

REFERENCES "SALON"."WORKER" ("WORKID") ENABLE,

CONSTRAINT "WORK_POST_POST_FK1" FOREIGN KEY ("POSTID")

REFERENCES "SALON"."POST" ("POSTID") ENABLE

) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ;

CREATE TABLE "SALON"."WORKER"

("WORKID" NUMBER NOT NULL ENABLE,

"NAME" VARCHAR2 (100 BYTE) NOT NULL ENABLE,

"PHONE" VARCHAR2 (25 BYTE) NOT NULL ENABLE,

"ADDRESS" VARCHAR2 (50 BYTE) NOT NULL ENABLE,

"WORKSINCE" DATE NOT NULL ENABLE,

CONSTRAINT "WORKER_PK" PRIMARY KEY ("WORKID")

USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ENABLE) SEGMENT CREATION IMMEDIATE

PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING

STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)

TABLESPACE "USERS" ;

Реализация представлений

Для создания удобства обращения пользователей к БД - можно создать представления.

1. Отображает информацию обо всех визитах клиентов, а также сотрудниках, их обслуживающих.

CREATE VIEW SALON.VISITINFO AS select visitid, cl.name nameclient, s.title, w.name, v."DATE" from salon.visit v

join salon.client cl on cl.clientid=v.clientid

join salon.service s on s.serviceid=v.serviceid

join salon.worker w on w.workid= v.workid

order by visitid

2. Отображает информацию о должностях сотрудников

create view salon.postinfo as

select p.title, w.name from salon.worker w join salon.work_post wp on w.workid= wp.workid

join salon.post p on wp.postid= p.postid

3. Отображает клиентов и все их визиты.

create view salon.clientvisitinfo as

select cl.name, s.title, v."DATE" from salon.visit v

join salon.service s on s.serviceid=v.serviceid

join salon.client cl on cl.clientid= v.clientid

3.2 Реализация триггеров

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

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

create or replace trigger salon.add_status

...