Указания по проектированию базы данных Описание предметной области
Предметная область - часть реального мира, которая представляет интерес для исследования, использования. В качестве предметной области могут выступать люди организации, явления природы, исторические сведения и многое другое. На начальным этапе проектирования БД проводиться анализ предметной области, осуществляется выделение ее объектов и связей между ними.
Описание предметной области должно включать в себя наименование, перечень основных понятий, описание основных процессов, базирующиеся на собственных знаниях о процессах («как есть») и описании процессов в литературе («как должно быть»). В описании должны быть указаны все особенности и характеристики процессов, последовательность действий, исходные и итоговые документы, приведены образцы этих документов.
Сокращенный пример описания предметной области для темы «Учет рабочего времени рабочих бумажного предприятия»:
Бумажное производство работает круглосуточно, рабочие работают 24 часа в сутки. Существуют должности, на которых в сутках работают в 3 смены по 8 часов каждая и есть должности, на которых в сутках работают в 2 смены по 12 часов каждая. Рабочие объединены в бригады. На 8 часовых сменах работает 4 бригады, т.е. одна бригада раз в три дня отдыхает. На 12 часовых сменах соответственно работает 3 бригады. Бригады работают и в праздники и в выходные. Инженеры работают только в дневную смену, 8 часов в сутки, не работают в праздники и выходные дни. У всех специалистов существует отпуск, продолжительностью 28 календарных дней, который положен один раз в год. Также специалист может брать отгулы, больничные в соответствии с ТК РФ.
График работы бригад и инженеров составляется на месяц вперед и называется табелем учета рабочего времени. В случае отклонения от данного графика в течение месяца в него вносятся корректировки.
Рис. 1 Пример табеля для одного из цехов.
Информация о принадлежности рабочих к бригадам, их должностях, принадлежности инженеров к отделам, их должностях находится в документе «Штатное расписание».
Рис. 2 Пример штатного расписания.
В данном проекте мы будем учитывать рабочее время специалистов на каждый день.
Основные понятия:
Смена
Бригада
Должность
Специалист
Подразделение (отдел, бригада)
Литература и нормативные документы:
Трудовой кодекс РФ;
Камышников В.А. Организация, планирование и управление на предприятиях деревообрабатывающей промышленности. Учебное пособие / Камышников В.А., Руднев В.Д. – Томск: Изд-во ТГАСУ, 2003
Медведев Н.А. Научные основы управления и организации труда в лесопромышленном производстве. – М., 2003.
Петров Б.С. Организация, планирование и управление на деревообрабатывающих предприятиях / Б.С. Петров, В.Н. Окладский, Р.А. Акимова Р.А.: Учебник для вузов. – М., 2002.
Ситхина Д.Е. Научная организация и нормирование труда на деревообрабатывающих предприятиях / Д.Е. Ситхина, А.Б. Петров – М., 2003.
Проектирование логической модели базы данных
IDEF1X основываются на диаграмме сущность-связь, которая была предложена в 1976 году сотрудником корпорации IBM Питером Ченом.
Сущность (entity) - это "предмет", который может быть идентифицирован некоторым способом, отличающим его от других "предметов".
Каждая сущность обладает набором атрибутов. Атрибут - отдельная характеристика сущности.
Сущность состоит из экземпляров, каждый из которых должен отличаться от другого экземпляра. Пример: сущность - сотрудник, экземпляр сущности сотрудник - Петров Виктор Сергеевич.
Связь (relationship) - это логическая ассоциация, устанавливаемая между сущностями, которая представляет бизнес-правило или ограничение.
Сущность отображается прямоугольником, где сверху прямоугольника представлено название сущности. Прямоугольник делится горизонтальной линией, где атрибуты представленные выше линии являются атрибутами первичного ключа, а ниже линии представлены неключевые атрибуты.
Первичный ключ - это набор атрибутов, однозначно определяющих каждую строку реляционной таблицы.
Атрибут первичного ключа - атрибут, значение которого позволяет уникально идентифицировать экземпляр сущности. Атрибут первичного ключа является частью первичного ключа, который необходим, для того чтобы отличать экземпляры сущности друг от друга. Первичный ключ может быть простым - состоящим из одного атрибута и составным - состоящим из нескольких атрибутов.
Внешний ключ это набор атрибутов одной таблицы, являющийся первичным ключом другой таблицы. Внешний ключ используется для организации логических связей между таблицами. Они используются для того, чтобы связать данные одной таблицы с данными в другой таблице.
Связи отображаются как линии между сущностями. В зависимости от роли в связи сущность может быть родительской или дочерней. В методике IDEF1X у дочерней сущности на связи присутствует точка. Каждая связь имеет глагольную фразу, которая характеризует связь. Глагольная фраза читается по следующей формуле = название родительской сущности + глагольная фраза + название дочерней сущности. Иногда для большей ясности разработчики используют вторую глагольную фразу, которая читается по формуле = название дочерней сущности + глагольная фраза + название родительской сущности.
Существует два типа сущностей:
зависимая сущность. Для определения экземпляра такой сущности необходимо сослаться на экземпляр независимой сущности, с которой связана зависимая сущность. Пример: сущности - заказ и позиция заказа. Для идентификации позиции заказа нужно сослаться на заказ, в который входит данная позиция.
независимая сущность. Для определения экземпляра сущности нет необходимости ссылаться на другие сущности. Пример: сущности - заказ и позиция заказа. Для определения заказа (сущности) нет необходимости ссылаться на позиции этого заказа (другие сущности).
Существует несколько видов связей:
идентифицирующая. Идентифицирующая связь указывает на то, что дочерняя сущность в связи является зависимой от родительской сущности, т.е. экземпляр зависимой сущности может быть однозначно определен, только если в этом экземпляре есть ссылка на экземпляр независимой сущности.
Идентифицирующая связь в обеих методиках отображается сплошной линией, причем дочерняя сущность является зависимой и поэтому отображается прямоугольником со скругленными углами.
Идентифицирующая связь
неидентифицирующая. Неидентифицирующая связь показывает на зависимость между родительской и дочерней сущностями, при этом экземпляр дочерней сущности может быть однозначно идентифицирован без ссылки на экземпляр родительской сущности.
Неидентифицирующая связь в обеих методиках отображается штриховой линией.
Неидентифицирующая связь
многие ко многим. Неспецифичный тип связи, во многом свидетельствует о незавершенности анализа. На конечных этапах моделирования данных все связи многие-ко-многим преобразуются в другие (идентифицирующие и неидентифицирующие) типы связей. В связи многие-ко-многим не выделяется родительская и дочерняя сущность и, как правило, используется две глагольных фразы.
Связь многие-ко-многим
иерархическая. Указывает на связь сущности саму на себя.
Иерархическая связь
Нормализация данных.
Процедура нормализации стремится к тому, чтобы все данные были только в одном месте. Другими словами, нормализация заключается в «выкидывании» дублирующихся полей. (Если же мы, наоборот, вставляем дублирующие поля в базу данных, то такой процесс называется денормализацией).
Ф. Кодд выделил существование 5 форм нормализации. Но на практике обычно используют первые три нормальные формы.
Первая нормальная форма.
Первая нормальная форма требует, чтобы на любом пересечении строки и столбца находилось единственное значение, которое должно быть атомарным, то есть оно не может быть разбито на составляющие. Кроме того, в таблице, удовлетворяющей первой нормальной форме, не должно быть повторяющихся групп, а также пустых первичных ключей.
Занимаясь поисками повторяющихся полей, разбейте на компоненты все составные столбцы: например в «отделе кадров» столбец ФИО нужно разбить на два столбца - Фамилия и Имя Отчество, поскольку человек по тем или иным причинам может поменять фамилию. (Возможен вариант отдельного хранения столбцов Имя и Отчество по той же причине, что и Фамилия).
Вторая нормальная форма.
Второе правило нормализации требует, чтобы любой неключевой столбец зависел от всего первичного ключа. Следовательно, представление таблицы во второй нормальной форме требует, чтобы все столбцы, не являющиеся первичными ключами (столбцы, описывающие объект, но однозначно не идентифицирующие его), зависели от всего первичного ключа, а не от его отдельных компонентов.
Вторая нормальная форма напрямую связана с правилом выбора первичного ключа, то есть с определением уникального идентификатора. Если естественный ключ был выбран неправильно, то второе правило нормализации выполняться не будет.
Третья нормальная форма.
Третья нормальная форма повышает требования второй нормальной формы: она не ограничивается составными первичными ключами, а требует, чтобы ни один неключевой столбец не зависел от другого неключевого столбца. Любой неключевой столбец должен зависеть только от столбца первичного ключа. Другими словами, любой неключевой столбец зависит только от всего ключа и больше ни от чего, кроме ключа.
Например, если бы Idn_города и его название находились в одной таблице (Клиент), то данная таблица содержала бы два связанных поля. А это не удовлетворяет третьей нормальной форме. Поэтому мы и выделили столбец города в отдельную таблицу.
Пример проектирования сокращенной логической модели базы данных:
Задание: спроектировать БД предназначенную для учета и планирования техобслуживания и ремонта оборудования.
Нарушение 1НФ:
Если оборудование ни разу не ремонтировадось, то в первичном ключе будет пустой столбец (дата начала ремонта);
На пересечения строки и столбца (ЗЧиМ для ремонта) не атомарное значение, т.к. для ремонта может требоваться больше одной ЗЧ.
Нарушение 2НФ:
Вид ремонта не зависит от первичного ключа таблицы Факты ремонта
Нарушение 3НФ:
Тип оборудования зависит от модели.
Готовая модель:
