💸 Как сделать бизнес проще, а карман толще?

Тот, кто работает в сфере услуг, знает — без ведения записи клиентов никуда. Мало того, что нужно видеть свое раписание, но и напоминать клиентам о визитах тоже. Проблема в том, что средняя цена по рынку за такой сервис — 800 руб/мес или почти 15 000 руб за год. И это минимальный функционал. Нашли самый бюджетный и оптимальный вариант: сервис VisitTime.
⚡️ Для новых пользователей первый месяц бесплатно. А далее 290 руб/мес, это в 3 раза дешевле аналогов. За эту цену доступен весь функционал: напоминание о визитах, чаевые, предоплаты, общение с клиентами, переносы записей и так далее.
✅ Уйма гибких настроек, которые помогут вам зарабатывать больше и забыть про чувство «что-то мне нужно было сделать».
Сомневаетесь? нажмите на текст, запустите чат-бота и убедитесь во всем сами!

Этапы проектирования концептуальной модели

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

Методика проектирования концептуальной модели состоит из следующих этапов:

1. Преобразование сущностей в отношения.

2. Установление свойств атрибутов.

3. Определение внешних ключей.

4. Реализация связей типа «многие-ко-многим».

Этап 1. Преобразование сущностей в отношения.

На данном этапе каждой сущности необходимо поставить в соответствие одно отношение. Отношению дается имя, допустимое в рамках выбранной СУБД. Отношение имеет тот же состав атрибутов, что и сущность, только атрибутам отношения также присваиваются допустимые имена. Первичный ключ отношения соответствует ключевому атрибуту сущности.

В описание данного этапа проектирования включаются диаграммы перехода от сущности к соответствующему отношению.

Пример. Преобразование сущности ЧИТАТЕЛЬ в отношение READER:

Этап 2. Определение свойств атрибутов отношений.

В реляционной модели данных атрибуты отношений имеют множество свойств – тип данных, размер, уникальность, возможность использования null-значений и т.д. Каждая конкретная СУБД поддерживает свое подмножество из всего множества свойств атрибутов. Рассмотрим минимальный набор свойств, поддерживаемый практически любой СУБД: тип данных, размер, возможность использования null-значений.

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

Пример. В данном примере используются следующие типы данных:

· Int – целый;

· Varchar(30) – строковый с максимальной длиной 30 символов;

· Date – дата.

Таблица 1.14. Свойства атрибутов отношения READER

Указание Not Null означает, что значения данного атрибута не могут быть пустыми, т.е. null-значениями. Для первичного ключа всегда указывается Not Null.

Этап 3. Определение внешних ключей.

На данном этапе производится анализ всех связей типа 1: М в следующем порядке:

1. Рассматривается очередная связь между сущностями из таблицы 1.12 с типом связи 1: М. Соответствующие отношения также являются связанными с тем же типом связи.

2. Анализируются атрибуты отношений, которые являются дочерними по отношению к другим. Если среди атрибутов дочернего отношения есть атрибут, ссылающийся на значения первичного ключа родительской таблицы, то данный атрибут объявляется внешним ключом. Иначе, в дочернее отношение добавляется новый атрибут, ссылающийся на первичный ключ родительского отношения. Этот атрибут будет являться внешним ключом, ему присваивается имя, которое может совпадать с именем первичного ключа родительского отношения.

3. На внешний ключ накладываются следующие ограничения: внешний ключ должен быть определен на том же типе данных, что и первичный ключ; если дочернее отношение является обязательным участником связи, то для внешнего ключа должно быть установлено “NOT NULL”, иначе – “NULL”.

4. Результат определения внешнего ключа вносится в таблицу:

Таблица 1.15. Перечень внешних ключей.

В графе «Ссылка» необходимо указать имя родительской таблицы и имя ее первичного ключа. Если свойства внешнего ключа корректируются, то в графе «Примечание» необходимо указать «КОРРЕКТИРОВКА»; если происходит добавление внешнего ключа, то необходимо указать «ДОБАВЛЕНИЕ».

Этап 4. Реализация связей типа «многие-ко-многим».

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

Пусть . Пусть - первичный ключ отношения , – первичный ключ отношения . Вводится отношение-связка , состоящая из атрибутов и . Первичным ключом отношения будет являться множество атрибутов . Таким образом, вместо одной связи типа M: M будем иметь две связи типа и .

Данный этап выполняется в следующем порядке:

1. Рассматривается очередная связь между сущностями из таблицы 1.12 с типом связи М: М. Соответствующие отношения также являются связанными с тем же типом связи.

2. В концептуальную модель базы данных вводится новое отношение-связка, желательно с именем, отражающим его смысл. Например, между отношением TOVAR и POSTAVSCHIK можно ввести отношение-связку с именем POSTAVKA.

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

4. Оба внешних ключа объявляются обязательными («NOT NULL») и в совокупности образуют первичный ключ отношения связки.

5. При необходимости, в состав отношения-связки можно ввести дополнительные атрибуты. Например, в отношение POSTAVKA, кроме обязательных атрибутов - внешних ключей kod_tovara и nomer_postavschika, можно включить атрибут data_postavki. Новым атрибутам необходимо присвоить имена, определить их свойства.

6. В результате для каждого отношения-связки должна быть оформлена таблица:

Таблица 1.16. Свойства атрибутов отношения-связки